O comando git pull é usado para buscar e baixar conteúdo de um repositório remoto e atualizar na hora o repositório local para que tenha o mesmo conteúdo. Fazer merge de alterações remotas de upstream em seu repositório local é uma tarefa comum em fluxos de trabalho de colaboração baseados em Git. O comando git pull é, na verdade, uma combinação de dois outros comandos git fetch seguido por git merge. Na primeira etapa da operação, git pull vai executar um git fetch do escopo para o ramo local ao qual HEAD está apontado. Depois que o conteúdo for baixado, git pull vai entrar em um fluxo de trabalho de merge. Um novo commit de merge vai ser criado e HEAD vai ser atualizado para apontar para 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. Em seguida, um git merge é executado para fazer a merge de refs e heads (cabeçalhos) de conteúdo remoto em um novo commit de merge local. Para demonstrar melhor o processo de download e merge, considere o exemplo a seguir. Suponha que a gente tem um repositório com um branch principal e uma origem remota.

Neste cenário, o git pull vai baixar todas as alterações a partir do ponto em que o local e o master divergiram. Neste exemplo, esse ponto é E. O git pull vai buscar os commits remotos divergentes, que são A-B-C. O processo do git pull vai criar um novo commit de merge local com o conteúdo dos novos commits remotos divergentes.

No diagrama acima, a gente pode ver o novo commit H. Esse é um commit de merge novo, com o conteúdo de commits remotos A-B-C e tem uma mensagem de log combinada. Este exemplo é uma das poucas estratégias de merge git pull. Uma opção --rebase pode ser passada para o git pull, para usar uma estratégia de merge de rebase em vez de um commit de merge. O próximo exemplo vai demonstrar como funciona um rebase pull. Suponha que a gente está no ponto de partida do primeiro diagrama e executou git pull --rebase.

Neste diagrama, veja que um rebase pull não cria o novo commit H. Em vez disso, o rebase copiou e anexou os commits remotos A--B--C ao histórico de confirmação de origem/master local.

Opções comuns

git pull <remote>

Busque a cópia remota especificada do branch atual e faça o merge de imediato na cópia local. Isto é o mesmo que git fetch <remote> seguido por 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 o ramo remoto com o 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.

Você começa pensando que seu repositório está sincronizado, mas então o git fetch revela que a versão master da origem progrediu desde a última vez que você verificou. Em seguida, git merge integra de imediato o master remoto no local.

Git pull e sincronização

O git pull é um dos muitos comandos que reivindicam a responsabilidade de "sincronizar" o conteúdo remoto. O comando git remote é usado para especificar em quais terminais remotos os comandos de sincronização vão funcionar. O comando git push é usado para carregar conteúdo em um repositório remoto.

O comando git fetch pode ser confundido com o git pull. Ambos são usados para baixar conteúdo remoto, mas há uma diferença de segurança importante entre git pull e get fetch. O git fetch pode ser considerado uma opção “segura”, enquanto git pull pode ser considerado inseguro.O git fetch vai baixar o conteúdo remoto e não alterar o estado do repositório local. Por sua vez, o git pull vai baixar o conteúdo remoto e tentar alterar o estado local na hora para corresponder a esse conteúdo. Isso pode, sem querer, fazer com que o repositório local fique em um estado de conflito.

Fazendo pull por rebase

A opção --rebase pode ser usada para garantir um histórico linear, evitando commits de merge desnecessários. Muitos desenvolvedores preferem fazer o rebase em vez do merge, como se dissessem: "Quero colocar minhas mudanças acima do que todos os outros fizeram". Neste sentido, usar o git pull com o sinalizador —rebase é ainda mais parecido com o svn update do que com um simples git pull.

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 apontando para o branch atual.

Git pull em remotos

git checkout new_feature
git pull <remote repo>

Este exemplo primeiro faz uma verificação e muda para o branch <newfeature>. Em seguida, o git pull é executado passando o <remote repo>. Isso vai baixar implicitamente o branch da nova funcionalidade do <remote repo>. Quando o download terminar, começa um git merge.

Git pull rebase em vez de merge

O exemplo a seguir demonstra como sincronizar com o branch master do repositório central usando um rebase:

git checkout master
git pull --rebase origin

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