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

Nota do moderador. Dado que já foram enviadas sessenta e sete respostas a esta questão (algumas delas foram eliminadas), considere se está a adicionar algo novo antes de enviar outro.

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

10.500
15 нояб. set pupeno 15 nov. 2008-11-15 12:51 '08 às 12:51 2008-11-15 12:51
@ 46 respostas
  • 1
  • 2

Nos termos mais simples, git pull executa uma git fetch seguida por git merge .

Você pode fazer git fetch a qualquer momento para atualizar as ramificações de rastreamento remotas em refs/remotes/<remote>/ .

Esta operação nunca altera nenhuma das suas próprias ramificações locais nos refs/heads e é segura sem alterar a cópia de trabalho. Eu até ouvi dizer que as pessoas periodicamente executam o git fetch em um cron job em segundo plano (embora eu não recomende isso).

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

Documentação do Git: Git Pull

8755
15 нояб. Resposta dada por Greg Hewgill em 15 de novembro 2008-11-15 12:52 '08 às 12:52 2008-11-15 12:52
  • Quando você usa pull , o Git tenta fazer o seu trabalho automaticamente para você. Isso é sensível ao contexto , então o Git irá mesclar quaisquer commits de push na ramificação em que você está trabalhando atualmente. pull mescla automaticamente as confirmações sem permitir que você as veja primeiro Se você não for muito bom em gerenciar suas ramificações, poderá encontrar conflitos freqüentes.

  • Quando você fetch , o Git coleta quaisquer commits da ramificação de destino que não existem em sua ramificação atual, mas armazena-os em seu repositório local . No entanto, não os combina com o seu ramo atual . Isso é especialmente útil se você precisar atualizar constantemente seu repositório, mas trabalhe no que pode quebrar se você atualizar seus arquivos. Para integrar confirmações no ramo principal, use a merge .

border=0
1919
18 авг. Resposta dada por Mouna Cheikhna 18 ago. 2011-08-18 11:53 '11 às 11:53 2011-08-18 11:53

É importante contrastar a filosofia de design do git com a filosofia de uma ferramenta de gerenciamento de origem mais tradicional, como o SVN.

O Subversion foi projetado e construído usando um modelo cliente / servidor. Há um repositório, que é um servidor, e vários clientes podem extrair código do servidor, trabalhar com ele e, em seguida, transferi-lo de volta para o servidor. Supõe-se que o cliente sempre possa entrar em contato com o servidor quando ele precisar executar uma operação.

O Git foi projetado para suportar um modelo mais distribuído sem a necessidade de um repositório central (embora você possa certamente usá-lo se quiser). Além disso, o git foi projetado de tal maneira que o cliente e o "servidor" não devem estar online ao mesmo tempo. O Git foi projetado para que as pessoas em um link não confiável possam até mesmo trocar o código por e-mail. Você pode desabilitar completamente o trabalho e gravar um CD para trocar códigos através do git.

Para suportar este modelo, o git mantém um repositório local com seu código, assim como um repositório local adicional que reflete o estado do repositório remoto. Ao armazenar uma cópia do repositório remoto localmente, o git pode determinar as mudanças necessárias, mesmo se o repositório remoto não estiver disponível. Mais tarde, quando você precisar enviar alterações para outra pessoa, o git poderá transferi-las como um conjunto de alterações do ponto no tempo conhecido para o repositório remoto.

  • git fetch é um comando que diz: "Traga minha cópia local do repositório remoto para a data."

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

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

Remova isso para ter em mente que geralmente há pelo menos três cópias do 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 é sua cópia de trabalho, onde você edita e constrói. A terceira cópia é sua cópia "em cache" local do repositório remoto.

1066
31 марта '13 в 21:43 2013-03-31 21:43 a resposta é dada por MikeD 31 de março de 2013 às 21:43 2013-03-31 21:43
711
09 июня '15 в 16:30 2015-06-09 16:30 a resposta é dada Contango 09 de junho '15 às 4:30 pm 2015-06-09 16:30

Um uso de git fetch é que a seguinte mensagem informará sobre quaisquer alterações na ramificação remota desde o último pull ... para que você possa verificar antes de fazer o pull real, que pode alterar os arquivos em sua ramificação atual e executar uma cópia .

 git fetch git diff ...origin 
437
07 мая '10 в 22:23 2010-05-07 22:23 a resposta é dada a mepster May 07, '10 at 10:23 AM 2010-05-07 22:23

Eu tive que entender um pouco 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 para o host local. Isto significa que neste momento você tem o ponteiro de origem / mestre em HEAD e o mestre apontando para o mesmo HEAD .

quando você começa a trabalhar e faz isso, você transfere o ponteiro mestre para HEAD + suas fixações. Mas o ponteiro de origem / mestre ainda indica o que foi quando você clonou.

Assim, a diferença será:

  • Se você executar git fetch , ele simplesmente extrairá todas as mudanças no repositório remoto ( GitHub ) e moverá o ponteiro start / master para HEAD . Enquanto isso, seu assistente local continuará indicando onde está localizado.
  • Se você fizer git pull , ele basicamente extrairá (como explicado anteriormente) e mesclará quaisquer novas mudanças na ramificação principal e moverá o ponteiro para HEAD .
347
11 мая '12 в 21:37 2012-05-11 21:37 a resposta é dada Gerardo 11 de maio, '12 at 21:37 2012-05-11 21:37

Às vezes, uma apresentação visual ajuda.

2019

25 янв. a resposta é dada pelo passageiro de 25 de janeiro. 2016-01-25 20:28 '16 às 8:28 pm 2016-01-25 20:28

brevemente

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

git pull descartado do console e instantaneamente mesclado.

Mais

git clone clones repos.

git rebase salva o material de sua ramificação atual que não está na ramificação crescente para a área temporária. Seu segmento agora é o mesmo de antes de você iniciar suas alterações. Assim, git pull -rebase retirar as alterações excluídas, rebobinar sua filial local, repetir as alterações no topo da ramificação atual, uma por uma, até que você esteja atualizado com os desenvolvimentos mais recentes.

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:

Diferença entre git pull, git fetch e git clone (e git rebase) - Mike Pierce

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

====

ATUALIZAÇÃO

Eu pensei que estava atualizando para mostrar como você realmente usou isso na prática.

  1. Atualize seu repositório local de um dispositivo remoto (mas não se una):

     git fetch 
  2. Depois de baixar as atualizações, veja as diferenças:

     git diff master origin/master 
  3. Se você está feliz com essas atualizações, mesclar:

     git pull 

Notas:

Na etapa 2: para obter mais informações sobre as diferenças entre dispositivos locais e remotos, consulte a Seção: Como comparar uma ramificação git local com uma ramificação remota?

Na etapa 3: O mais provável é que seja mais preciso (por exemplo, em um repositório de mudanças rápidas) para fazer a git rebase origin . Veja @Justin Ohms Comente em outra resposta.

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

170
13 апр. Responder Snowcrash 13 de abr 2013-04-13 20:31 '13 às 8:31 pm 2013-04-13 20:31
 git-pull - busca e mescla com outro repositório ou filial local SINOPSE git puxar ... DESCRIÇÃO Executa o git-fetch  cabeça (s) recuperada (s) no ramo atual.  Com --rebase, chama git-rebase  em vez de git-merge. Note que você pode usar.  (diretório atual) como o <repositório> para puxar  do repositório local - isso é útil ao mesclar ramificações locais  no ramo atual. Git-pull  para git-fetch.

Você puxaria, se quiser que as histórias sejam mescladas, você obteria se quisesse "o código", porque algumas delas colocaram alguns artigos aqui.

161
15 нояб. Resposta dada por Vinko Vrsalovic em 15 de nov 2008-11-15 12:52 '08 às 12:52 2008-11-15 12:52

Você pode extrair do repositório remoto, ver as diferenças e puxar ou mesclar.

Este é um exemplo de um repositório remoto denominado origin e um ramo denominado master , que rastreia a origin/master ramificação origin/master remota:

 git checkout master git fetch git diff origin/master git rebase origin master 
147
21 марта '11 в 14:07 2011-03-21 14:07 a resposta é dada por Antonio Bardazzi 21 de março de 2011 às 14:07 2011-03-21 14:07

A resposta curta e simples é que git pull é apenas git fetch seguido por git merge .

É muito importante notar que o git pull funde automaticamente, quer você goste ou não . Isso, obviamente, pode levar a conflitos de mesclagem. Digamos que seu console seja de origin e seu ramo seja master . Se você é git diff origin/master antes de puxar, você deve estar ciente de potenciais conflitos de mesclagem e pode preparar sua ramificação local de acordo.

Além de puxar e clicar, alguns fluxos de trabalho incluem o git rebase , por exemplo, este, que parafraseei de um artigo relacionado:

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

Se você se encontrar nesta situação, você pode ser tentado pelo git pull --rebase . Se você realmente não sabe o que está fazendo, eu aconselho a fazê-lo. Este é um aviso da man page para git-pull , versão 2.3.5 :

Este é um modo de operação potencialmente perigoso. Ele reescreve uma história que não augura nada de bom quando você já publicou essa história. Não use este parâmetro se você não leu cuidadosamente o git-rebase (1).

139
15 мая '11 в 23:53 2011-05-15 23:53 a resposta é dada por jfmercer May 15, '11 at 23:53 2011-05-15 23:53

2019

117
06 февр. a resposta é dada em 6 de fevereiro 2015-02-06 14:48 '15 às 14:48 2015-02-06 14:48

Bem , aqui estão algumas informações sobre git pull e git fetch , para que você possa entender as diferenças reais ... em poucas palavras simples, fetch obtém os dados mais recentes, mas não altera o código e não entra em contato com seu código de ramificação local atual, mas retira o código com as alterações e mesclar em sua filial local, continue lendo para obter informações mais detalhadas sobre cada um:

git fetch

Ele irá baixar todos os links e objetos e quaisquer novas ramificações para o seu repositório local ...

Escolha ramos e / ou tags (juntos, "refs") de um ou mais outros repositórios, junto com os objetos necessários para completar suas histórias. Filiais de rastreamento remoto atualizadas (consulte a descrição abaixo para saber como controlar esse comportamento).

Por padrão, qualquer tag que aponta para as histórias extraídas também é recuperada; o efeito é extrair tags que apontam para os ramos em que você está interessado. Esse comportamento padrão pode ser alterado usando as opções --tags ou --no-tags ou definindo o remote..tagOpt. Usando o refspec, que extrai tags explicitamente, você pode extrair tags que não apontam para as ramificações nas quais você está interessado.

O git fetch pode ser recuperado de um único repositório ou URL nomeado, ou de vários repositórios de uma vez, se fornecidos, e há consoles. escreva no arquivo de configuração. (Veja Git-config 1 ).

Se nenhum dispositivo remoto for especificado, a origem inicial padrão será usada, a menos que uma ramificação upstream esteja configurada para a ramificação atual.

Os nomes dos links selecionados, juntamente com os nomes dos objetos para os quais eles apontam, são registrados em git / FETCH_HEAD. Esta informação pode ser usada por scripts ou outros comandos git, como git-pull.


git pull

Ele aplicará as alterações do remoto ao ramo atual no local ...

Inclui mudanças de um repositório remoto para o ramo atual. No modo padrão, git pull é uma abreviação de git fetch, seguida por git merge FETCH_HEAD.

Mais especificamente, git pull executa git fetch com os parâmetros fornecidos e chama git merge para mesclar os cabeçalhos de ramificação recebidos na ramificação atual. Usando o --rebase, ele executa git rebase em vez de git merge.

deve ser o nome do repositório remoto passado para git-fetch 1 . pode chamar uma referência remota arbitrária (por exemplo, o nome da tag) ou até mesmo uma coleção de links com ramificações de rastreamento remotas correspondentes (por exemplo, refs / heads /: refs / remotes / origin /), mas geralmente esse é o nome da ramificação no repositório remoto.

Os valores padrão para e são lidos a partir das configurações "remote" e "merge" para a ramificação atual, conforme definido por git-branch --track.


Eu também crio uma imagem visual abaixo para mostrar como git fetch e git pull funcionam juntos ...

2019

Bônus:

Falando de alongamento e extração nas respostas acima, eu gostaria de compartilhar um truque interessante,

git pull --rebase

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

Antes de enviar novos commits para o servidor, tente este comando e ele sincronizará automaticamente as mudanças mais recentes do servidor (usando fetch + merge) e colocará sua mensagem no início no log git. Não precisa se preocupar com mão puxando / fusão.

Encontre informações em: http://gitolite.com/git-pull--rebase

113
23 дек. A resposta é dada por Sazzad Hissain Khan em 23 de dezembro. 2015-12-23 18:31 '15 às 18:31 2015-12-23 18:31

Eu gosto de ter algum tipo de representação visual da situação para entender essas coisas. Talvez outros desenvolvedores também gostariam de ver isso, então aqui está minha adição. 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 . . . FETCH *------------------>* Your local cache of the remote is updated with the origin (or multiple external sources, that is git 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. 

Alguns dos principais benefícios de ter uma imagem espelhada do console são:

  • Performance (rolando todos os commits e mensagens sem tentar comprimir através da rede)
  • Feedback sobre o status do seu repositório local (por exemplo, eu uso o Atlassian SourceTree, que me dará uma lâmpada indicando se eu irei avançar ou retroceder em comparação com a fonte. Atualizar com o GIT FETCH).
107
20 февр. A resposta é dada por Justus Romijn em 20 de fevereiro. 2014-02-20 00:18 '14 às 0:18 2014-02-20 00:18

Eu também lutei com isso. Na verdade, cheguei aqui com a pesquisa do Google para exatamente a mesma pergunta. Depois de ler todas estas respostas, finalmente desenhei uma imagem na minha cabeça, e decidi tentar lidar com o estado de dois repositórios e um sandbox, e as ações executadas com o tempo, assistindo a sua versão. Então, foi isso que eu criei. Por favor, corrija-me se eu estraguei tudo.

Três repositórios com uma amostra:

 --------------------- ----------------------- ----------------------- - 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+ - --------------------- ----------------------- ----------------------- 

Três repositórios com uma carga

 --------------------- ----------------------- ----------------------- - 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 a amostragem é muito importante.

95
17 июля '12 в 19:43 2012-07-17 19:43 a resposta é dada pn1 cara julho 17 '12 em 7:43 pm 2012-07-17 19:43

A diferença entre o GIT Fetch e o GIT Pull pode ser explicada pelo seguinte cenário: (Lembrando que as imagens falam mais que palavras! Eu forneci uma representação gráfica)

Vamos supor que você esteja trabalhando em um projeto com membros de sua equipe. Assim, eles serão uma das principais divisões do projeto, e todos os participantes devem ramificar-se em seu próprio repositório local e, em seguida, trabalhar nessa ramificação local para alterar / adicionar módulos e, em seguida, retornar à ramificação principal.

Então, o estado inicial das duas ramificações, quando você bifurca o projeto principal em seu repositório local, será assim - ( A , B e C são os módulos já concluídos no projeto)

2019

ответ дан Aman Tiwari 07 февр. '17 в 17:15 2017-02-07 17:15