example - git pull origin master




Qual é a diferença entre 'git pull' e 'git fetch'? (20)

Qual é a diferença entre git pulle git fetch?

Para entender isso, primeiro você precisa entender que o seu git local mantém não apenas seu repositório local, mas também mantém uma cópia local do repositório remoto.

git fetchtraz sua cópia local do repositório remoto até à data. Por exemplo, se o seu repositório remoto for o GitHub - você pode querer buscar quaisquer alterações feitas no repositório remoto para sua cópia local do repositório remoto. Isso permitirá que você realize operações como comparar ou mesclar.

git pullpor outro lado, derrubará as alterações no repositório remoto para onde você mantém seu próprio código. Normalmente, git pullfará o git fetchprimeiro para atualizar a cópia local do repositório remoto e, em seguida, mesclará as alterações em seu próprio repositório de código e possivelmente em sua cópia de trabalho.

Moderador Nota: Como essa pergunta já teve sessenta e sete respostas postadas (algumas delas excluídas), considere se você está ou não contribuindo com algo novo antes de postar outra.

Quais são as diferenças entre git pull e git fetch ?


Bônus:

Ao falar de pull & fetch nas respostas acima, eu gostaria de compartilhar um truque interessante,

git pull --rebase

Este comando acima é o comando mais útil na minha vida que salvou muito tempo.

Antes de enviar seus novos commits para o servidor, experimente este comando e ele sincronizará automaticamente as mudanças mais recentes do servidor (com uma busca + mesclagem) e colocará seu commit no topo no log git. Não precisa se preocupar com pull manual / merge.

Encontre detalhes em: http://gitolite.com/git-pull--rebase


É importante contrastar a filosofia de design do git com a filosofia de uma ferramenta de controle de fonte mais tradicional como o SVN.

O Subversion foi projetado e construído com um modelo cliente / servidor. Existe um único repositório que é o servidor, e vários clientes podem buscar o código do servidor, trabalhar nele e depois enviá-lo de volta ao servidor. A suposição é que o cliente sempre pode entrar em contato com o servidor quando precisar executar uma operação.

O Git foi projetado para suportar um modelo mais distribuído sem necessidade de um repositório central (embora você possa certamente usar um, se quiser). O git também foi projetado para que o cliente e o "servidor" não precisem estar on-line ao mesmo tempo. O Git foi projetado para que as pessoas em um link não confiável pudessem trocar códigos via e-mail, mesmo. É possível trabalhar completamente desconectado e gravar um CD para trocar código via git.

Para suportar esse modelo, o git mantém um repositório local com seu código e também um repositório local adicional que espelha o estado do repositório remoto. Mantendo uma cópia do repositório remoto localmente, o git pode descobrir as mudanças necessárias mesmo quando o repositório remoto não está acessível. Mais tarde, quando você precisar enviar as alterações para outra pessoa, o git poderá transferi-las como um conjunto de alterações de um ponto no tempo conhecido pelo repositório remoto.

  • git fetch é o comando que diz "atualize minha cópia local do repositório remoto".

  • git pull diz "traga as mudanças no repositório remoto para onde eu mantenho meu próprio código".

Normalmente o git pull faz isso fazendo uma git fetch para atualizar a cópia local do repositório remoto e, em seguida, mesclando as mudanças em seu próprio repositório de código e possivelmente em sua cópia de trabalho.

A ideia é ter em mente que muitas vezes há pelo menos três cópias de um projeto em sua estação de trabalho. Uma cópia é seu próprio repositório com seu próprio histórico de confirmação. A segunda cópia é a sua cópia de trabalho, onde você está editando e construindo. A terceira cópia é sua cópia "em cache" local de um repositório remoto.


A resposta curta e fácil é que git pull é simplesmente git fetch seguido por git merge .

É muito importante notar que git pull irá se fundir automaticamente, quer você goste ou não . Isso poderia, obviamente, resultar em conflitos de mesclagem. Digamos que seu controle remoto seja de origin e seu ramo seja master . Se você git diff origin/master antes de puxar, você deve ter alguma idéia de possíveis conflitos de mesclagem e pode preparar sua ramificação local de acordo.

Além de puxar e empurrar, alguns fluxos de trabalho envolvem o git rebase , como este, que parafraseei do artigo vinculado:

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

Se você se encontrar em tal situação, você pode ser tentado a git pull --rebase . A menos que você realmente saiba o que está fazendo, eu aconselho contra isso. Este aviso é da página man do git-pull , versão 2.3.5 :

Este é um modo de operação potencialmente perigoso. Reescreve a história, o que não augura nada de bom quando você já publicou essa história. Não use esta opção a menos que tenha lido o git-rebase (1) com cuidado.


Custou-me um pouco entender qual era a diferença, mas esta é uma explicação simples. master em seu localhost é um ramo.

Quando você clona um repositório, você obtém todo o repositório no host local. Isso significa que, nesse momento, você tem um ponteiro de origem / mestre para HEAD e o mestre apontando para o mesmo HEAD .

quando você começar a trabalhar e fizer com que você avance o ponteiro mestre para HEAD + seus commits. Mas o ponteiro de origem / mestre ainda está apontando para o que era quando você clonou.

Então a diferença será:

  • Se você fizer uma git fetch ele irá apenas buscar todas as mudanças no repositório remoto ( GitHub ) e mover o ponteiro de origem / mestre para HEAD . Enquanto isso, seu mestre de filial local continuará apontando para onde está.
  • Se você fizer um git pull , ele basicamente buscará (como explicado anteriormente) e mesclará quaisquer novas mudanças em sua ramificação master e moverá o ponteiro para HEAD .

Nos termos mais simples, o git pull faz uma git fetch pelo git merge seguido por um git merge .

Você pode fazer uma git fetch a qualquer momento para atualizar suas ramificações de rastreamento remoto sob refs/remotes/<remote>/ .

Essa operação nunca altera nenhuma das suas próprias ramificações locais sob refs/heads , e é seguro fazê-lo sem alterar sua cópia de trabalho. Eu até ouvi falar de pessoas correndo git fetch periodicamente em um cron job em segundo plano (embora eu não recomendaria fazer isso).

Um git pull é o que você faria para atualizar uma filial local com sua versão remota, além de atualizar suas outras ramificações de rastreamento remoto.

Documentação do Git: git pull


Você pode buscar em um repositório remoto, ver as diferenças e, em seguida, puxar ou mesclar.

Este é um exemplo para um repositório remoto chamado origin e uma ramificação chamada master rastreamento da origin/master filial remota:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

git fetchirá recuperar os ramos remotos para que você possa git diffou git mergeeles com o ramo atual. git pullirá executar buscar no brach remoto rastreado pelo ramo atual e depois mesclar o resultado. Você pode usar git fetchpara ver se há alguma atualização na ramificação remota sem precisar mesclá-las com sua ramificação local.


Brevemente

git fetch é semelhante ao pull mas não se mescla. isto é, ele busca atualizações remotas ( refs e objects ), mas seu local permanece o mesmo (ou seja, origin/master é atualizado, mas o master permanece o mesmo).

git pull puxa para baixo de um controle remoto e instantaneamente se funde.

Mais

git clone clona um repo.

git rebase salva o material de sua ramificação atual que não está no branch upstream para uma área temporária. Sua filial agora é a mesma de antes de você iniciar suas alterações. Então, git pull -rebase irá puxar as mudanças remotas, rebobinar sua filial local, repetir suas mudanças sobre a parte superior de sua ramificação atual, uma por uma, até que você esteja atualizado.

Além disso, git branch -a mostrará exatamente o que está acontecendo com todas as suas filiais - local e remota.

Esta postagem do blog foi útil:

A diferença entre git pull, git fetch e git clone (e git rebase) - Mike Pearce

e abrange git pull , git fetch , git clone e git rebase .

====

ATUALIZAR

Eu pensei em atualizar isso para mostrar como você realmente usa isso na prática.

  1. Atualize seu repo local do controle remoto (mas não mescle):

    git fetch

  2. Depois de baixar as atualizações, vamos ver as diferenças:

    git diff mestre origem / mestre

  3. Se você está feliz com essas atualizações, então mesclar:

    git pull

Notas:

No passo 2: Para mais informações sobre diffs entre locais e remotos, veja: comparar ramificações git locais com ramificações remotas?

No passo 3: É provavelmente mais preciso (por exemplo, em um repo de mudança rápida) para fazer uma git rebase origin aqui. Veja o comentário de @Justin Ohms em outra resposta.

Veja também: longair.net/blog/2009/04/16/git-fetch-and-merge


Git Fetch

Você faz o download das alterações para sua ramificação local desde a origem até a busca. O Fetch pergunta ao repositório remoto por todos os commits que outros fizeram, mas você não tem em seu repositório local. Buscar os downloads desses commits e adiciona-os ao repositório local.

Git Merge

Você pode aplicar as alterações baixadas por meio da busca usando o comando merge. A mesclagem levará os commits recuperados da busca e tentará adicioná-los à ramificação local. A mesclagem manterá o histórico de commits de suas alterações locais, de modo que quando você compartilhar sua branch com push, o Git saberá como os outros podem mesclar suas alterações.

Git Pull

Buscar e mesclar executados juntos com freqüência suficiente para que um comando que combina os dois, pull, seja criado. Pull faz uma busca e, em seguida, uma mesclagem para adicionar os commits baixados em sua filial local.


Nós simplesmente dizemos:

git pull == git fetch + git merge

Se você executar git pull, não precisará mesclar os dados ao local. Se você executar git fetch, isso significa que você deve executar git mergepara obter o código mais recente para sua máquina local. Caso contrário, o código da máquina local não seria alterado sem mesclar.

Então, no Git Gui, quando você busca, você precisa mesclar os dados. A busca em si não fará o código mudar no seu local. Você pode verificar isso quando você atualizar o código, buscando uma vez buscar e ver; o código não vai mudar. Então você mescla ... Você verá o código alterado.


Na verdade, o Git mantém uma cópia do seu próprio código e do repositório remoto.

O comando git fetchatualiza sua cópia local obtendo dados do repositório remoto. A razão pela qual precisamos disso é porque alguém pode ter feito algumas alterações no código e você quer se manter atualizado.

O comando git pulltraz as mudanças no repositório remoto para onde você guarda seu próprio código. Normalmente, git pullisso é feito primeiro fazendo uma "busca do git" para atualizar a cópia local do repositório remoto e, em seguida, mesclar as alterações em seu próprio repositório de código e possivelmente em sua cópia de trabalho.


Tentando ser claro e simples.

O comando git pull é na verdade um shortcutpara git fetch seguido pelo git merge ou git rebase, dependendo da sua configuração. Você pode configurar seu repositório Git para que git pull seja uma busca seguida por um rebase.


Uma representação gráfica simples para iniciantes,

Aqui,

git pull  

irá buscar código do repositório e rebase com o seu local ... no git pull existe a possibilidade de novos commits serem criados.

mas em ,

git fetch

irá buscar o código do repositório e precisamos rebase-lo manualmente usando git rebase

Por exemplo: eu vou buscar do mestre do servidor e rebase-lo no meu mestre local.

1) git pull (rebase será feito automaticamente):

git pull origin master

aqui a origem é o seu repo master remoto é o seu ramo

2) git fetch (precisa se rebase manualmente):

git fetch origin master

ele irá buscar as mudanças do servidor de origem. e estará em seu local até que você o rebase sozinho. Precisamos corrigir os conflitos manualmente, verificando códigos.

git rebase origin/master

isso irá rebase o código para local. antes disso, garanta que você está no ramo certo.


Esta representação gráfica interativa é muito útil para entender o git: http://ndpsoftware.com/git-cheatsheet.html

git fetch apenas "baixa" as mudanças do remoto para o seu repositório local. git pull download das alterações e as mescla em sua ramificação atual. "Em seu modo padrão, o git pull é uma forma abreviada de git fetch seguida por git merge FETCH_HEAD ."


A única diferença entre git pulle git fetché isso:

git pull puxa de um ramo remoto e mescla-lo.

git fetch só busca do ramo remoto, mas não se fundem

ou seja, git pull = git buscar + git merge ...


Eu gosto de ter alguma representação visual da situação para entender essas coisas. Talvez outros desenvolvedores também gostariam de ver, então aqui está minha adição. Eu não tenho certeza se tudo está correto, então, por favor, comente se você encontrar algum erro.

                                         LOCAL SYSTEM
                  . =====================================================    
================= . =================  ===================  =============
REMOTE REPOSITORY . REMOTE REPOSITORY  LOCAL REPOSITORY     WORKING COPY
(ORIGIN)          . (CACHED)           
for example,      . mirror of the      
a github repo.    . remote repo
Can also be       .
multiple repo's   .
                  .
                  .
FETCH  *------------------>*
Your local cache of the remote is updated with the origin (or multiple
external sources, that is git's distributed nature)
                  .
PULL   *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur, 
you are asked for decisions.
                  .
COMMIT            .                             *<---------------*
When coming from, for example, subversion, you might think that a commit
will update the origin. In git, a commit is only done to your local repo.
                  .
PUSH   *<---------------------------------------*
Synchronizes your changes back into the origin.

Algumas vantagens importantes para ter um espelho buscado do controle remoto são:

  • Desempenho (percorra todos os commits e mensagens sem tentar espremer através da rede)
  • Feedback sobre o estado do seu repositório local (por exemplo, eu uso o SourceTree da Atlassian, que me dará uma lâmpada indicando se eu estou comprometido com antecedência ou atrasado em comparação com a origem. Essa informação pode ser atualizada com um GET FETCH).

Eu lutei com isso também. Na verdade eu cheguei aqui com uma pesquisa no google exatamente da mesma pergunta. Lendo todas estas respostas, finalmente, pintei uma imagem na minha cabeça e decidi tentar fazer isso para baixo, olhando para o estado dos dois repositórios e um sandbox e ações realizadas ao longo do tempo, enquanto assistia a versão deles. Então aqui está o que eu criei. Por favor, corrija-me se eu errei em qualquer lugar.

Os três repos com uma busca:

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - fetch               -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     -                     -
- @ R01             -     - @ R01+              -     - @R01+               -
---------------------     -----------------------     -----------------------

Os três repos com um puxão

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - pull                -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     - merged with R02     -
- @ R01             -     - @ R01+              -     - @R02+               -
---------------------     -----------------------     -----------------------

Isso me ajudou a entender por que uma busca é muito importante.


git-pull - Fetch from and merge with another repository or a local branch
SYNOPSIS

git pull   …
DESCRIPTION

Runs git-fetch with the given parameters, and calls git-merge to merge the 
retrieved head(s) into the current branch. With --rebase, calls git-rebase 
instead of git-merge.

Note that you can use . (current directory) as the <repository> to pull 
from the local repository — this is useful when merging local branches 
into the current branch.

Also note that options meant for git-pull itself and underlying git-merge 
must be given before the options meant for git-fetch.

Você puxaria se quisesse que as histórias fossem mescladas, você buscaria se você apenas "quisesse o codez", já que algumas pessoas têm etiquetado alguns artigos por aqui.


git pull = git fetch + git merge 




git-fetch