Meu Notebook
Lays Marie Hidani
Sumário
Git e GitHub são duas coisas diferentes.
Git é um sistema de controle de versões. Todo o trabalho acontece na sua máquina (computador)
Já o GitHub é uma plataforma de hospedagem, controle de versão e colaboração. Funciona como uma espécie de "rede
social" colaborativa dos programadores. Podendo visualizar o seu código e de toda a comunidade dentro da
plataforma, clonar, etc.
Faça o download do Git
Acesse o GitHub
É um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo. O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos.
Cada diretório de trabalho do Git é um repositório com um histórico completo e habilidade total de acompanhamento das revisões, não dependente de acesso a uma rede ou a um servidor central.
-Wikipedia-
O workflow básico do Git pode ser descrito assim:
- Você modifica arquivos no seu diretório de trabalho.
- Você seleciona os arquivos, adicionando snapshots deles para sua área de preparação.
- Você faz um commit, que leva os arquivos como eles estão na sua área de preparação e os armazena permanentemente no seu diretório Git.
- GIT -
Os comandos e interação do Git se dá pelo terminal (prompt de comando/shell/etc), após a instalação, também serão adicionados dois novos terminais a sua máquina (built-in do Git): o Git CMD (padrão Windows) e o Git Bash (padrão MacOs e Linux).
Mesmo que seu OS seja Windows, Mac ou Linux, você pode optar por usar qualquer um dos terminais GitCMD ou Git Bash.
Você pode optar por usar o terminal de sua própria máquina, ou os terminais do Git, ou mesmo qualquer outro de sua preferência.
Você poderá ainda usar o GUI ("Graphical User Interface"), onde, ao invés de executar os comandos via terminal, você poderá usar uma interface gráfica. O próprio Git já vem com um GUI na instalação (built-in): o Git GUI, mas existem outros para baixar conforme a sua preferência. Acesse o link abaixo para fazer o download: GUIs
GitHub é uma plataforma de hospedagem de código-fonte com controle de versão usando o Git. Ele permite que programadores, utilitários ou qualquer usuário cadastrado na plataforma contribuam em projetos privados e/ou Open Source de qualquer lugar do mundo. GitHub é amplamente utilizado por programadores para divulgação de seus trabalhos ou para que outros programadores contribuam com o projeto, além de promover fácil comunicação através de recursos que relatam problemas ou mesclam repositórios remotos (issues, pull request).
-Wikipedia-O GitHub é uma plataforma de hospedagem de código para controle de versão e colaboração. Ele permite que você e outros trabalhem juntos em projetos de qualquer lugar.
-GitHub- Saiba mais
Basta acessar o site do GitHub e se cadastrar para começar a usar o site.
É o primeiro estado do arquivo. Os arquivos estão na sua máquina, mas não estão aos cuidados do Git. Uma vez
adicionado (add) ao Git, ele não volta mais ao estado de untracked.
Depois de dar o comando "add" ao Git, os arquivos passam para a área "staged", onde o git já está cuidando dos arquivos e está de olho em todas as alterações que estão acontecendo.
Em uma definição livre, pode ser considerada uma área de preparo, uma espécie de "palco", onde o Git assiste da plateia todas as modificações :)
Não é um passo essencialmente obrigatório. Podendo simplesmente usar o atalho de adicionar juntamente com o
commit, porém é muito útil para ter mais controle sobre as alterações antes de commitar. Dessa forma, é
recomendada.
Depois que comitamos o arquivo ele passa para a área "commited", que em uma tradução livre, consolida todas as
mudanças do arquivo, oficializa.
Sempre que ocorrer uma modificação no arquivo, ele sairá de "commited" e passará para uma nova área chamada "modified".
Quando o arquivo é "add" pela primeira vez ele sai de "untracked" (não rastreado) e passa a ser rastreado pelo Git, dessa forma, ele não irá voltar a estar em "untracked".
Ao invés disso, sempre que houver uma modificação, ele sairá de
"commited" e passará para "modified", aguardando ser adicionado (add) a "staged" novamente e depois ser commitado.
Utilizaremos para esses exemplos o terminal Git Bash.
Antes de executar os comandos de Git, o terminal deverá sempre estar configurado para a pasta do repositório em questão. Ver # Diretório do repositório
A configuração inicial deve ser feita somente quando inicia-se um novo repositório. Em repositórios já existentes, pula-se essa etapa.
git config --global user.name nome_de_usuarioTipos de usuário:
Assim, pode-se configurar como global, local, ou system, dependendo do caso. Na maior parte das vezes, utiliza-se global.
git config --global user.email e-mail
ex: git config --global user.email meuemail@gmail.com
git config --global --list
Pode abreviar usando --l ao invés de --list
ex: git config --global --l
Basta executar o comando config de novo.
git config --global --unset user.nameNeste caso, levando em consideração que foi configurado usuário como global.
git config --global --unset emailNeste caso, levando em consideração que foi configurado usuário como global.
cd caminho_da_pastaDicas de abreviação/atalho
ex:
cd desktop/projetos/site
Para listar os arquivos da pasta
ls
cd .git
ls
Este comando será muito utilizado durante o uso do Git, por ele poderemos visualizar qual o status de nossos
arquivos, se untracked, modified, staged, commited..
git status
git status -u
git init
Se por algum motivo não deseja mais usar o controle de versões e deseja desligar o Git do repositório (esse
comando irá remover/deletar o Git do repositório em questão):
rm -rf .git/
Na primeira vez que você for fazer push de um repositório de sua máquina para o GitHub (somente a primeira vez mesmo, os próximos repositórios não necessitarão dessa autenticação), você deverá gerar um conjunto de chaves SSH, uma pública e uma privada, elas servirão para autenticar seus gits no GitHub. Onde sua Chave pública do github será autenticada pela chave privada da sua máquina. Não se preoculpe que não é tão complicado quanto parece. Para acessar o passo-a-passo do próprio GitHub, basta acessar: link
No terminal digite o comando abaixo. Você deverá informar o mesmo e-mail que está cadastrado no GitHub
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
O prompt irá informar que está gerando as chaves. depois disso irá perguntar onde você deseja salvar a chave privada, se quiser no local já sugerido pelo git, basta teclar ENTER.
Depois disso ele irá perguntar se você deseja salvar uma senha adicional, geralmente não é necessário, então basta teclar ENTER. caso for inserir senha, deve-se digitar a senha e depois confirmar a mesma.
Entre no diretório das chaves salvas:
cd ~/.ssh/
Depois irá mostrar o nome das chaves, a que interessa é a .pub, copie o nome dela. Pode usar o comando [cat] ou
[more].
Digite:
cat id_rsa.pub
Irá aparecer sua chave pública no terminal..copie.
Vá no site do Github, clique em sua imagem de perfil
(botão verde no canto superior direito da tela) >>>
settings (lado esquerdo da tela) >>> SSH and GPG keys >>> new SSH key (botão verde no canto superior direito da
tela) >>> Digitar o
nome/titulo (geralmente coloca-se o nome do seu pc) e colar a chave >>> Add SSH Key.
git remote add origin endereço_sshgit push origin master
Quando quiser verificar se o repositório está conectado, digite:git remote
(deverá aparecer:
origin)
Para verificar detalhes: git remote -v
Os commits aparecem da ordem de criação mais recente para a mais antiga, e dizemos que o commit mais recente é
filho do mais antigo, sucessivamente.
Ex:
$ git log --oneline
a7b2440 (HEAD -> master) c4 - alterações
d6ec6be C3 - Acresc nome do curso e prof
13e1d6c C2a - outro html chamado curso com o link do curso
bd5dcc8 C2 - add novo paragrafo
98f7dd4 C1 - h1 e parágrafo
e0a52d7 C0 - Primeiro commit
Então: C0 é pai de C1, C1 é pai de C2, C4 é filho de c3, etc.
git log --parents --oneline
Adiciona o arquivo para os cuidados do git (stage: área do Git)
git add nome do arquivo.extensão
Para adicionar todos os arquivos de uma vez:
git add .
Commitar (o git tira uma “foto” do estado atual do projeto p/ acompanhar as mudanças)
git commit -m “mensagem de minha preferência”
Ex: git commit -m “C0 - Primeiro commit do projeto”
Obs: *Se vc não colocar a mensagem, automaticamente ele irá abrir um editor de texto para que você digite a mensagem.
Neste caso, digite a mensagem no editor que irá abrir, crtl + S para salvar e depois feche o editor, ou digite q no git bash (se tiver aberto dentro do próprio prompt do git) para sair do editor.
git commit -am “mensagem de minha preferência”
O editor de texto padrão do Git é o VIM, durante a instalação você também recebe um opção de alterar essa
configuração. Mas se por algum motivo, depois de instalado, desejar mudar o editor padrão:
git config --global core.editor nome do editor que deseja
Sempre que quiser atualizar uma mudança no repositório, repetir:
git add nome_do_arquivo_extensãogit commit + mudanças realizadas ex: git commit -m “C1 - Alterações na parte de css do código”)
Uma vez, que devemos passar os arquivos de MODIFIED para COMMITED novamente.
Sempre que ocorre alguma mudança em um arquivo, o Git inteligentemente irá mostrar no terminal todas as alterações sofridas pelo documento, com linhas na cor verde e sinal (+) para as linhas de código que são adicionadas ao arquivo e cor vermelha e sinal (-) para o que é retirado.
Para visualizar todos os commits realizados Modo completo (tecle ENTER ou seta para baixo até chegar ao final
(end).. para sair: tecle (q)
git log
git log --oneline
Para visualizar o ultimo commit em uma linha:
git log -1 --oneline
Para visualizar os 2 últimos commits em uma linha:
git log -2 --oneline
Assim, por diante, basta trocar o número. Para verificar não resumidos em uma linha, basta tirar o trecho de código --oneline.
Você visualizar todos os commits realizados no repositório independentemente da branch, através do comando:
git log --oneline --all
Ou para ficar ainda melhor, é possível verificar graficamente:
git log --oneline --all --graph
Visualização completa, contendo modificações realizadas:
git show número_da_hash
Você pode encontrar a hash de cada commit através do comando
git log --oneline
>>> Por exemplo, quero informações sobre o commit C5, cuja hash é 574cc01.
Digito no terminal:
git show 574cc01
Para Visualização resumida (sem info sobre linhas de código modificadas):
git log -1 stat
git log -p -posição_do_commit
Ex: Exibir histórico com diff das duas últimas alterações:
git log -p -2
git log --pretty=format:"%h - %an, %ar : %s"
Onde:
git log -- caminho_do_arquivo
git log --summary -S
O M pode ser substituido por: Adicionado (A), Copiado (C), Apagado (D), Modificado (M), Renomeado (R), entre
outros.
git log --diff-filter=M --
git log --author=nomedoautor
Ex:
git log --author=hlays
Serve para listar todos os arquivos que não deverão ser lançados no repositório, ou seja, que estão na pasta mas
deverão ser ignorados pelo git. Recomenda-se criar apenas um único gitignore em trabalhos em grupo e commitá-lo,
assim todos terão
acesso aos nomes dos arquivos ignorados e evita de que um mesmo arquivo seja ignorado mais vezes por outras
pessoas.
No github
Passos:
fonte.txt
img21.png
Vamos supor que queremos que o git ignore todos os arquivos em formato txt que estão na pasta. Basta salvar no
arquivo .gitignore * + extensão do tipo de arquivo a ser ignorado (no editor de texto):
*.txt
git add -f nome_do_arquivo.extensão
Para comparar:
git diff
git diff --staged ou git diff --cached
git diff hash_do_commit_antigo..hash_do_commit_atual
Geralmente de um arquivo que você acabou de mexer e ainda não fez commit das últimas atualizações.
O console irá mostrar todas as modificações realizadas que estão diferentes da última atualização commitada
pelo git (compara modified e commited).
Em verde (+) tudo o que foi acrescentado e em vermelho (-) tudo o que foi removido.
Tecle ENTER ou seta para baixo até chegar ao final do documento (END) e então tecle (q) para sair.
Comando:
git diff
git diff nome_do_arquivo.extensão
Para visualizar modificações que não estão em modified acrescentar (--staged ou --cached)
git diff --staged
git diff hash_do_commit_antigo..hash_do_commit_atual
Exemplo. Dados os commits abaixo, para comparar C5 e C6:
Lays@Krasco MINGW64 ~/desktop/teste_git (master)
$ git log --oneline
99a627b (HEAD -> master) c7 - atualizações diversas
6d30e14 C7 - mudanças no corpo do projeto
fc5cbee C6 - arquivo git ignore
574cc01 C5 - Acrescentado img e algumas alterações
a7b2440 c4 - alterações
d6ec6be C3 - Acresc nome do curso e prof
13e1d6c outro html chamado curso com o link do curso
bd5dcc8 "add novo paragrafo em
-> comando : git diff 574cc01..fc5cbee
Resumindo...
Supondo que você deseja desfazer alterações no arquivo..vai depender em que ponto ele está: untracked, modified,
commited.
* Ao invés de desfazer, o mais aconselhado é reverter, para ao invés de apenas deletar a alteração, manter
documentado. Ver reverter mais abaixo.
git checkout --nome_do_arquivo.extensão
git reset nome_do_arquivo.extensão
git checkout --nome_do_arquivo.extensão
Tirar arquivo de commit e passar de volta para staged, sem deletar o arquivo, usa-se o comando --soft + a hash do
pai, ou seja, a hash do commit anterior ao que eu quero apagar. e depois é possível fazer o checkout.
git reset --soft hash_do_pai
Tirar arquivo de commit e passar para modified (fora do staged), sem deletar o arquivo, usa-se o comando --mixed +
a hash do pai, ou seja, a hash do commit anterior ao que eu quero apagar e depois é possível fazer o checkout.
git reset --mixed hash_do_pai
Tirar arquivo de commit e deletar o arquivo (todos os commits e arquivos que estão depois do que o commit em
questão deixam de existir, são deletados e fica só do commit pai/anterior para baixo). Usa-se o comando --hard + a
hash do pai, ou seja, a hash do commit anterior ao que eu quero apagar e depois é possível fazer o checkout.
git reset --mixed hash_do_pai
Quase semelhante ao desfazer, mas nesse caso será criado um commit que indica a reversão. É o mais aconselhado.
Com mensagem sobre a reversão, neste caso o editor de texto irá abrir para que você insira a mensagem sobre o por
que da reversão, ou digite (-m “mensagem”) após o hash
git revert hash_do_commit_a_ser_revertido
Sem mensagem sobre a reversão:
git revert hash_do_commit_a_ser_revertido --no-edit
Quando deletar um arquivo do arquivo local de sua máquina, o git irá reconhecer isso e se você verificar no
comando
Deve-se:
git rm nome_do_arquivo.extensão
git commit
OU
git add nome_do_arquivo.extensão
git commit
Os dois métodos são distintos. Quando removemos pelo sistema operacional ou por alguma ide e queremos commitar essa ação, temos que add ao stage e commitar. Agora se commitarmos diretamente pelo git (com git rm) não precisamos fazer o add, pois a deleção já vai para a stage. Nesse caso é só um corte de caminho para não precisar usar o git add.
git checkout -- nome_do_arquivo.extensão
git rm nome_do_arquivo.extensão
git rm -r nome da pasta
git add do arquivogit statusgit commit
git mv nome_antigo.extensão novo_nome.extensãogit statusgit commit para consolidar a mudançaQuando usar pela primeira vez, deverá conectar a sua conta do Github na sua máquina, para isso, é necessário Connectar o SSH da sua conta. Onde sua Chave pública do github será autenticada pela chave privada da sua máquina. link para instruções
No terminal, digite:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
O terminal irá informar que está gerando as chaves.
Depois disso irá perguntar onde você deseja salvar a chave
privada, se quiser no local já sugerido pelo git, basta teclar ENTER.
Depois disso ele irá perguntar se você deseja salvar uma senha adicional, geralmente não é necessário, então basta teclar ENTER. caso for inserir senha, deve-se digitar a senha e depois confirmar a mesma.
Digite no terminal para entrar no diretório das chaves salvas:
cd ~/.ssh/
O terminal irá mostrar o nome das chaves, a que interessa é a .pub, copie o nome dela. Pode usar o comando
cat ou more. Digite:
cat id_rsa.pub
Irá aparecer sua chave pública no terminal (um conjunto de caracteres com diversas linhas..copie.
Agora, vá no site do Github, clique em sua imagem de perfil (botão verde no canto superior direito da tela) >>> settings (lado esquerdo da tela) >>> SSH and GPG keys >>> new SSH key (botão verde no canto superior direito da tela) >>> Digitar o nome/titulo (geralmente coloca-se o nome do seu pc) e colar a chave >>> Add SSH Key.
git remote add origin endereço_ssh. Este nome git push origin master
git remote
Deve aparecer: origin, ou o nome que você tenha usado.
git remote -v
Sempre que quiser atualizar os commits locais também no Github fazer:
git push origin master
Este é o inverso. Quando você cria o repositório no Github e deseja trazer para a máquina, não basta fazer um
simples download do repositório, pois não seria uma cópia completa, uma vez que, faria uma cópia dos arquivos
simplesmente e não do repositório em si com o Git.
Será necessário clonar o repositório remoto utilizando o comando
Não esqueça de estar com o local que deseja salvar o repositório configurado no terminal
git clone endereço_do_repositorio
você deverá encontrar o endereço SSH do repositório na página do repositório do Github. Fica localizado em um
botão verde do lado direito da tela. Você pode clonar tantos seus próprios repositório, quanto em repositórios
criados por outras pessoas com quem irá trabalhar no projeto em questão.
git pull origin master
origin, ou o nome que você tenha usado..
Geralmente, se você colabora com repositórios da empresa onde trabalha, ou em projetos opensource, por exemplo,
dos quais você faz parte da equipe, quando você desejar enviar seus commits com alterações do repositório em
questão, precisará estar ajustado no Git como
Para isso, o dono do repositório deverá ir até a página do repositório em questão, clicar em
Assim, sendo um colaborador, toda vez que enviar um commit, o dono do repoitório será notificado sobre suas alterações e deverá permitir ou não que elas sejam consolidadas.
Geralmente, se você colabora com projetos opensource, por exemplo, dos quais você deseja colaborar de alguma
forma, quando você faz alterações em arquivos e deseja commitá-los para o repositório original (que não foi criado
por você), deverá solicitar essa permissão através do botão
Isso permite o controle sobre o projeto, sem que qualquer um mexa no repositório sem permissão e evitando
alterações indesejadas.
Quando você faz um
Branches são como uma linha do tempo.
Quando você faz o 1º commit do seu repositório, o Git automáticamente cria a 1ª branch chamada
Quando necessário, você poderá criar outras branchs, como uma forma de ramificar o repositório e trabalhar em paralelo.
Exemplificando, vamos supor que você tenha um repositório do projeto de um site. Em algum momento você deseja
fazer algumas modificações para aprimorar o site, modificando todo o estilo css da página. Porém será um processo
mais demorado, e enquanto você continua a desenvolver o html, não quer que essas alterações em andamento do css
prejudiquem ou até impessam seu trabalho com o html.
Ao mesmo tempo, você não pode simplesmente fazer um gitignore do css, pois afetaria o desenvolvimento html.
Assim você, cria uma nova ramificação da parte css. E pode fazer commits para cada branch separadamente, do
html seguindo a linha do tempo principal
Assim, o último estado do css antes de ser ramificado da master, continuará lá ativo até que você termine as
alterações e volte a atualização final para a branch master.
Outra exemplificação seria, quando uma equipe deseja ramificar o trabalho de cada um, para permitir o trabalho em paralelo quando necessário.
git branch nome_da_nova_branch
>>> ATALHO <<<
É possível também criar uma branche e já ir para ela automaticamente sem a necessidade do comando git branch e
depois git checkout, para isso:
git checkout -b nome_da_nova_branch
A ramificação só é efetivada quando você commitar o arquivo na ramificação.
Não se esqueça de commitar com o terminal ajustado na branch como explicado no tópico anterior.
Quando criamos uma branch no repositório local, será necessário criar a mesma branch no repositório remoto.
Isso pode ser feito pelo próprio site do Github ou pelo terminal:
git branch master:nome_da_nova_branch
Lembrando que, quando trabalhamos em equipe, geralmente criamos ramificações somente no nosso repositório local, e ao final fazemos push somente do que é necessário no repositório remoto. Tudo isso vai depender de cada caso.
No tópico a seguir veremos um atalho para Criar branch já trackeada ao repositório remoto.
git branch nome_da_nova_branch origin/nome_da_nova_branch
git branch -a
git branch
git branch -r
Em qual branch estou?
com o comando git branch, o terminal mostrará todas as branchs existentes no repositório, e a branch em que
você está irá aparecer em verde com * (asterísco)
git log --oneline
O terminal irá mostrar todos os commits realizados e na 1ª linha, podemos verificar através de
Quando quiser mudar de branch para commitar, basta digitar no terminal:
git branch checkout nome_da_branch
Para deletar uma branch, é necessário que você não esteja nela. Então certifique-se de que está na branch master
antes de execultar o código.
git branch -d nome_da_branch_deletar
Pode acontecer de o Git acusar que a branch não foi completamente mesclada. Você pode mesclar corretamente e
excluir. Ou, caso queira excluir e não mesclar, não salvando assim o commit, basta trocar o -d por -D:
git branch -D nome_da_branch_deletar
git push --delete
Supondo que naquele exemplo anterior, você terminou suas alterações em paralelo no css e deseja que a brach "teste", seja mesclada com a master para prosseguir com o projeto em completo.
1º certifique-se que você esteja na branch "master" (se não estiver, use: branch checkout master)
A diferença entre mesclar branches com merge e com rebase:
No momento em que você cria a ramificação, o Git guarda o estado dos determinados arquivos e quando você faz
rebase, o Git compara os arquivos anteriores com os novos e é como se fizesse um novo commit e a ramificação,
praticamente, não tivesse existido.
Use o comando merge para mesclar:
git merge nome_da_branch_que _deseja_mesclar -m "mensagem sobre o commit"
No caso do exemplo:
git merge testar
Ou seja, uma vez, que já estamos em "master", informamos ao git para "trazer"/"mesclar" a branch testar com master.
Caso não tenha sido criado nenhum commit na branch master que entre em conflito com os commits do branch paralelo, temos o que chamamos de "fast-forward", os commits da branch passam automaticamente para a branch principal (master) sem conflito ou complicações.
Caso algum commit entre em conflito, o merge automático não vai funcionar, e temos que seguir alguns passos adicionais. Assim teremos que decidir como resolver o conflito com nossos arquivos, seja adicionando-os, ou excluindo, dependendo do caso.
Feito o merge certinho, podemos deletar a branch adicional, caso não seja mais necessária, seguindo os passos já
mencionados anteriormente (git branch -d nome_da_branch_a_deletar)
git rebase nome_da_branch_que_deseja_mesclar
Cuidado, sempre é aconselhavel somente fazer rebase em branchs locais, uma vez que fazer isso em branches compartilhadas com outras pessoas pode gerar conflitos.
Em alguns casos em que a branch master tiver commits à frente de outra branch, será necessário fazer um rebase ao contrário.
Ou seja, fazer o rebase a partir da outra branch para levar a master para lá (fazendo isso você iguala a linha do
tempo) e depois fazendo um novo rebase para levar/tombar da nova branch para a branch master. Isso irá gerar um
fast forward sem conflitos na branch master compartilhada.
Para ilustrar melhor esta situação, veja o exemplo:
Lembre-se que se o seu terminal estiver apontando para uma determinada branch, todas as alterações que você estiver fazendo sobre os documentos irão refletir naquela branch em questão.
Então, não se esqueça de alterar a branch quando necessário. Uma vez que alterações realizadas no mesmo documento local irão "aparecer" de maneira diferente no próprio documento, dependendo da branch em que você estiver.
Muitas vezes os conflitos entre arquivos acontecem justamente porque algumas linhas de código, por exemplo, estão de forma diferente dependendo da branch.
Por isso, para resolver esse tipo de conflito, é necessário ver qual linha do arquivo está desatualizada em relação à outra branch e atualizá-la.
Antes de finalizar o processo de rebase, para corrigir conflitos, etc, é possível cancelar a operação com:
git merge --abort
Algumas vezes podem ocorrer problemas de conflitos entre os commits, neste caso você deverá corrigir os conflitos e abortar o merge ou para continuar depois de corrigir basta fazer o merge novamente.
Antes de finalizar o processo de rebase, para corrigir conflitos, etc, é possível cancelar a operação com:
git rebase --abort
Algumas vezes podem ocorrer problemas de conflitos entre os commits, neste caso você deverá corrigir os conflitos
e abortar o rebase ou para continuar depois de corrigir, não é necessário começar a operação novamente como ocorre
com o merge, aqui podemos continuar de onde paramos com:
git rebase --continue
Pode acontecer durante os commits locais, de estar desatualizado no repositório remoto, para resolver isso:
git push -u origin master
Neste exemplo, na hora de fazer o push, acrescenta-se -u para atualizar e igualar a branch master nos repositórios. Lembrando que usamos "origin" como exemplo (conforme explicado é um nome que se dá), e usou-se a branch master, mas pode ser feito para qualquer outra branch que se deseja atualizar a posição.
Feito isso uma vez, a branch de ambos repositórios será sempre rastreada e atualizada durante os push normais.
Lembrando que os repositórios remotos que são clonados para o repositório local já vem trackeados
automaticamente.
Então se você "mandar" um git push ele já opera sozinho sem necessidade de acrescentar origin
master, por exemplo.
Quando fazemos um git push origin master para enviar as atualizações de commits para o repositório
git remote set-url origin https://github.com/USERNAME/REPOSITORY.git
git remote -v