git pull

O comando git pull é usado para buscar e baixar conteúdo de repositórios remotos e fazer a atualização imediata ao repositório local para que os conteúdos sejam iguais. Fazer o merge de alterações upstream remotas no repositório local é algo comum em fluxos de trabalho de colaboração baseados em Git. O comando git pull é a combinação de dois outros comandos, o git fetch, seguido do git merge. No primeiro estágio da operação, o git pull executa o comando git fetch, que abrange a ramificação local para qual a HEAD aponta. Quando o conteúdo é baixado, o git pull insere o fluxo de trabalho de merge. O commit de merge é criado e a HEAD é atualizada para apontar o novo commit.

Uso do Git pull

Como funciona

O comando git pull primeiro executa o git fetch, que baixa o conteúdo do repositório remoto especificado. Então, o git merge é executado e faz merge das refs e dos heads do conteúdo remoto para o novo commit de merge local. Para mostrar melhor o processo de pull e de merge, veja o exemplo a seguir. Suponha que a gente tenha um repositório com uma ramificação principal e uma origem remota.

Nesse caso, o git pull baixa todas as alterações a partir do ponto de divergência entre o local e a ramificação principal. Nesse exemplo, o ponto é E. O git pull busca os commits remotos divergentes, que são A-B-C. O processo de pull então cria o commit de merge local que tem o conteúdo dos novos commits remotos divergentes.

No diagrama acima, é possível ver o novo commit H. Esse commit de merge é novo e armazena o conteúdo dos commits remotos A-B-C e uma mensagem de log combinada. Essa é uma de várias estratégias de merge de git pull. O git pull também pode receber a opção --rebase para usar a estratégia de merge de rebase em vez do commit de merge. O próximo exemplo mostra como o pull de rebase funciona. Suponha que a gente esteja no ponto de partida do primeiro diagrama e tenha executado git pull --rebase.

Neste diagrama, veja que o rebase pull não cria o commit H. Em vez disso, o rebase copiou os commits remotos A--B--C e rescreveu os commits locais E--F--G para aparecerem depois deles no histórico de commits de origem/principal local.

Opções comuns

git pull <remote>

Busque a cópia remota especificada da ramificação atual e faça o merge de imediato na cópia local. É o mesmo que git fetch ＜remote＞ seguido de git merge origin/＜current-branch＞.

git pull --no-commit <remote>

Semelhante à invocação padrão, obtém o conteúdo remoto, mas não cria um novo commit de merge.

git pull --rebase <remote>

Igual ao pull anterior. Em vez de usar git merge para integrar a ramificação remota com a local, use git rebase.

git pull --verbose

Oferece uma saída especificada durante uma extração que exibe o conteúdo que está sendo baixado e os dados de merge.

Discussão sobre o git pull

Você pode pensar no git pull como a versão do Git do comando svn update. É uma maneira fácil de sincronizar seu repositório local com alterações upstream. O diagrama a seguir explica cada etapa do processo de extração.

Primeiro, você pensa que o repositório está sincronizado, mas então o git fetch revela que a versão principal da origem progrediu desde a última verificação. Em seguida, o git merge integra de imediato a ramificação principal remota na local.

Git pull e sincronização

O git pull é um dos muitos comandos que têm a responsabilidade de "sincronizar" conteúdo remoto. O comando git remote é usado para especificar em quais terminais remotos os comandos devem operar. O comando git push é usado para fazer upload de conteúdo em repositórios remotos.

O comando git fetch pode ser confundido com o git pull. Ambos são usados para baixar conteúdo remoto. Há diferenças de segurança importantes entre o git pull e o git fetch. O git fetch é a opção que pode ser considerada "segura", enquanto o git pull pode ser considerado "pouco seguro". O git fetch baixa o conteúdo remoto e não altera o estado do repositório local. Já o git pull baixa o conteúdo remoto e, de imediato, tenta alterar o estado local para que ele corresponda àquele conteúdo. Isso pode causar um estado conflituoso acidental no repositório local.

Fazendo pull por rebase

A opção --rebase pode ser usada para garantir o histórico linear, evitando o merge de commits desnecessários. Muitos desenvolvedores preferem o rebase em vez do merge, porque é como dizer: "Eu quero colocar minhas alterações acima do que todo mundo tem feito". Neste sentido, usar git pull com o sinalizador --rebase é mais como uma atualização de svn do que como um git pull simples.

Na verdade, o pull com --rebase é um fluxo de trabalho tão comum que existe uma opção de configuração dedicada para ele:

git config --global branch.autosetuprebase always

Depois de executar esse comando, todos os comandos git pull vão ser integrados via git rebase em vez de git merge.

Exemplos de Git pull

Os exemplos a seguir demonstram como usar o git pull em cenários comuns:

Comportamento padrão

git pull

Executar a invocação padrão do git pull é equivalente a git fetch origin HEAD e git merge HEAD, no qual HEAD é ref que aponta para a ramificação atual.

Git pull em remotos

git checkout new_feature
git pull <remote repo>

Primeiro, o exemplo faz o checkout e muda para a ramificação . Em seguida, o git pull é executado passando o . Isso faz o download implícito da ramificação newfeature de . Quando o download for concluído, o git merge vai ser iniciado.

Git pull rebase em vez de merge

O exemplo a seguir demonstra como sincronizar com a ramificação principal do repositório central usando um rebase:

git checkout main
git pull --rebase origin

Assim, suas mudanças locais ficam acima das contribuições dos colegas.