Sincronizar alterações com fetch, pull e push

Traz informações e commits do remoto para o repositório local, mas não integra essas mudanças à branch atual. Seus arquivos de trabalho permanecem como estavam.

Busca atualizações do remoto e as integra à branch atual. Portanto, pode atualizar seus arquivos de trabalho. Neste tutorial, usaremos pull com a estratégia de merge.

Envia commits locais para atualizar uma branch no remoto. O sentido é o contrário: do seu repositório para o GitHub, não do GitHub para sua branch local.

A referência de acompanhamento remoto origin/<nome-da-branch>, como origin/main, fica no seu repositório local. Ela representa o último estado conhecido daquela branch no remoto, não uma consulta em tempo real ao GitHub.

No terminal, dentro da pasta do projeto com origin configurado, execute:

O comando busca novos commits em origin e atualiza as referências de acompanhamento remoto configuradas — não apenas a correspondente à branch atual.

Sua branch atual não se move, e os arquivos de trabalho permanecem iguais, inclusive suas edições ainda não commitadas.

Após o git fetch origin, visualize o histórico com o comando abaixo. Nos exemplos, a branch é main: localize as etiquetas HEAD -> main e origin/main. No seu projeto, compare as referências com o nome real da branch.

Um commit é exclusivo de um lado quando faz parte daquele histórico, mas não do outro.

• Alinhados: as duas referências apontam para o mesmo commit.
• Local adiantada: só a branch local tem commits exclusivos.
• Local atrasada: só origin/main tem commits exclusivos.
• Divergentes: cada lado tem commits exclusivos.

Siga as conexões do grafo; não se baseie apenas na posição das linhas.

Quando main tem origin/main como upstream, git branch -vv e git status podem mostrar a diferença entre os históricos. Esses contadores usam referências locais: interprete-os após o fetch, sem tratá-los como uma consulta em tempo real ao GitHub.

• ahead 1: há 1 commit exclusivo de main.
• behind 2: há 2 commits exclusivos de origin/main.

Como os dois lados têm commits exclusivos, os históricos estão divergentes. Os números contam commits, não arquivos.

Após um novo fetch, main acompanha origin/main. Você executa git status --short --branch e obtém somente esta linha:

Neste exemplo, vamos atualizar a branch local site, que já existe. No seu projeto, use o nome real da branch.

Execute os comandos abaixo um de cada vez. Confira o estado antes da troca e antes da integração. Se houver alterações pendentes, registre o trabalho na branch adequada antes de continuar.

Depois de executar git fetch origin e inspecionar o histórico, integre com o comando abaixo. origin/site é a referência a integrar; quem recebe as mudanças é site, a branch atual. Não troque para origin/site.

A relação entre os históricos determina o resultado. Nos exemplos abaixo, o avanço direto está habilitado e as mudanças são compatíveis.

Com a branch de destino selecionada e a árvore de trabalho limpa, você pode encadear a busca e a integração. Neste exemplo, main acompanha origin/main.

O comando abaixo busca atualizações usando o upstream configurado e as integra por merge na branch atual. A opção --no-rebase explicita a estratégia de merge para esta execução.

Quer examinar as novidades antes de integrar? Use git fetch origin, inspecione o histórico e só então decida executar git merge origin/main, estando em main.

Quer buscar e integrar em sequência? Use git pull --no-rebase, com o upstream correto configurado. Ele não oferece uma pausa entre a busca e a integração para você examinar as novidades.

Aqui, main é o nome da branch do exemplo; no projeto, considere o nome real.

Você está na branch ajustes, com a árvore de trabalho limpa. Depois do último fetch, criou o commit local L. Nesse intervalo, uma colega publicou o commit R na mesma branch do GitHub. Seu envio é rejeitado:

Esse é um caso de atualização não fast-forward: sua branch ainda não contém R. Atualizar o remoto diretamente para L deixaria R fora do histórico dessa branch. Seus commits locais continuam intactos.

Repetir o mesmo push não resolve. O caminho é buscar novamente → inspecionar → integrar por merge → conferir → reenviar.

No cenário anterior, L é seu commit local e R é o commit da colega. O merge sem conflitos cria M, unindo as duas linhas de histórico:

Representação simplificada, não uma saída de comando.

Na branch main deste exemplo, um push foi rejeitado. Você buscou as novidades, inspecionou o histórico e executou git merge origin/main. A integração parou neste trecho de README.md:

Aplique a resolução de conflitos que você já conhece. Antes de retomar o push, confirme:

• O conteúdo final foi conferido e preserva as mudanças pretendidas dos dois históricos.
• O commit de merge foi registrado.
• git status não indica conflitos nem merge em andamento.

Só editar e preparar o arquivo não conclui a integração.

Neste exemplo, a branch se chama main. No seu projeto, use o nome real da branch.

Você está na branch ajustes-guia, que acompanha origin/ajustes-guia, com a árvore de trabalho limpa.

Seu commit documenta a execução no Linux. Antes do seu envio, uma colega publica instruções para Windows na mesma branch remota. Seu git push origin ajustes-guia é rejeitado por atualização não fast-forward.

Você executa git fetch origin e consulta o histórico com git log --oneline --graph --all --decorate:

Atualize novamente o conhecimento do remoto antes de conferir o alinhamento. Além dos comandos abaixo, abra o README.md: um merge concluído precisa preservar o resultado pretendido das duas contribuições.

Resumo ilustrativo, supondo que o remoto não recebeu outras mudanças: