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


11917

Quais são as diferenças entre git pulle git fetch?


364
Eu encontrei este artigo bem escrito sobre git fetch e git pull vale a pena a leitura: longair.net/blog/2009/04/16/git-fetch-and-merge
Marcos Oliveira

51
Nossa abordagem alternativa tornou-se git fetch; git reset --hard origin/masterparte do nosso fluxo de trabalho. Ele afasta as alterações locais, mantém você atualizado com o mestre, MAS garante que você não apenas puxe novas alterações por cima das alterações atuais e faça uma bagunça. Nós o usamos há um tempo e, basicamente, parece muito mais seguro na prática. Apenas certifique-se de adicionar / confirmar / esconder qualquer trabalho em andamento primeiro!
Michael Durrant

26
Certifique-se de saber como usar o git stash corretamente. Se você está perguntando sobre 'puxar' e 'buscar', então talvez 'esconderijo' também precisa explicar ...
Henry Heleine

36
Muitas pessoas que vêm do Mercurial continuam usando "git pull", pensando que é equivalente a "hg pull". O que não é. O equivalente do Git a "hg pull" é "git fetch".
Serge Shultz

8
git fetch comando buscar código atualizado com filial e também vai ficar ramos recém-adicionado em seu comando puxar local, git fetch único código atualizada do único ramo atual
Kartik Patel

Respostas:


9918

Nos termos mais simples, git pullfaz a git fetchseguido de a git merge.

Você pode fazer um git fetcha qualquer momento para atualizar suas ramificações de rastreamento remoto em refs/remotes/<remote>/.

Essa operação nunca altera nenhuma de suas próprias filiais locais refs/headse é segura sem alterar sua cópia de trabalho. Eu até ouvi falar de pessoas executando git fetchperiodicamente em um trabalho cron em segundo plano (embora eu não recomendo fazer isso).

A 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 :

No modo padrão, git pullé uma abreviação para git fetchseguido por git merge FETCH_HEAD.


326
"A" git pull "é o que você faria para atualizar seu repositório" <- a atualização do repositório já não foi realizada pela busca? não quer dizer que ele atualize suas filiais locais com as filiais remotas? Para mesclar: Ele mescla as ramificações remotas com suas cópias locais dessas ramificações, ou o que exatamente ele mescla aqui?
Albert

194
@ Albert: Sim, é estranhamente redigido. git pullsempre será mesclado na ramificação atual . Então, você seleciona qual ramo você quer puxar a partir de , e puxá-lo para o ramo atual. A ramificação from pode ser local ou remota; pode até ser um ramo remoto que não esteja registrado git remote(o que significa que você passa um URL na git pulllinha de comando).
intuited

129
@espertus: Não. Empurrar nunca faz uma mesclagem automaticamente. Espera-se que o usuário puxe, resolvendo conflitos de mesclagem localmente, e depois retorne ao controle remoto.
Greg Hewgill

33
Se eu estiver no /home/alice/e fizer git fetch /home/bob, quais parâmetros devo passar para o subseqüente git merge?
Ripper234

106
Nota para as pessoas que aprendem Git: pullna verdade, não pode ser emulado por um sinal de fetchmais a merge. Acabei de buscar uma alteração na qual apenas um ponteiro de ramificação remota muda e me mergerecuso a fazer qualquer coisa. pull, por outro lado, avança rapidamente meu ramo de rastreamento.
Roman Starkov

2173
  • Quando você usa pull, o Git tenta fazer seu trabalho automaticamente para você. Como é sensível ao contexto , o Git mescla quaisquer confirmações extraídas na ramificação em que você está trabalhando. pull Mescla automaticamente as confirmações sem permitir que você as revise primeiro . Se você não gerenciar de perto suas filiais, poderá ter conflitos frequentes.

  • Quando você fetch, o Git reúne quaisquer confirmações do ramo de destino que não existem no seu ramo atual e as armazena no repositório local . No entanto, ele não os mescla com sua ramificação atual . Isso é particularmente útil se você precisar manter seu repositório atualizado, mas estiver trabalhando em algo que pode quebrar se você atualizar seus arquivos. Para integrar as confirmações em sua ramificação principal, use merge.


34
Concordo, ótimo comentário. É por isso que eu odeio git pull. Quando faria sentido deixar uma ferramenta de revisão fazer edições de código para você? E não é isso que a fusão de dois arquivos está fazendo? E se essas duas edições forem fisicamente separadas no arquivo, mas logicamente em desacordo?
Lee Dixon

126
@elexhobby, colocar git fetchapenas o .git/diretório (AKA: repositório local) e nada fora .git/(AKA: árvore de trabalho). Ele não altera suas filiais locais e também não toca master. Toca remotes/origin/masterembora (veja git branch -avv). Se você tiver mais controles remotos, tente git remote update. Este é um git fetchpara todos os controles remotos em um comando.
Tino

24
O @Tino é realmente o ponto mais importante. As pessoas podem não saber que as ramificações "remotas" são realmente armazenadas como um monte de hashes .git/refs/remotes/origin/.
Chris

13
Quando você busca, o Git reúne todas as confirmações do ramo de destino que não existem na sua filial atual e as armazena no repositório local - como vejo o que foi trazido do controle remoto e como o mesclo nos meus ramos locais?
アレックス

13
@Tino O que eu ainda não entendo é ... qual é o objetivo? Por que usar buscar se ele apenas é atualizado .git? Qual é o benefício pretendido e o que devo fazer depois disso?
BadHorsie 23/03

1210

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

O Subversion foi projetado e construído com um modelo de cliente / servidor. Existe um único repositório que é o servidor e vários clientes podem buscar código do servidor, trabalhar nele e 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 a necessidade de um repositório central (embora você certamente possa usá-lo, se quiser). Também o git foi projetado para que o cliente e o "servidor" não precisem estar online ao mesmo tempo. O Git foi projetado para que pessoas em um link não confiável pudessem trocar código por e-mail. É 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 reflete o estado do repositório remoto. Mantendo uma cópia do repositório remoto localmente, o git pode descobrir as alterações 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 a partir de um momento conhecido no repositório remoto.

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

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

Normalmente git pull, isso é feito git fetchpara atualizar a cópia local do repositório remoto e, em seguida, mesclar as alterações no seu próprio repositório de código e possivelmente na sua cópia de trabalho.

O problema é ter em mente que geralmente 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 consolidação. A segunda cópia é a sua cópia de trabalho onde você está editando e construindo. A terceira cópia é sua cópia local "em cache" de um repositório remoto.


75
Tecnicamente, os repositórios locais e remotos são realmente o mesmo. No Git, um repositório é um DAG de confirmações apontando para seus pais. As ramificações são, tecnicamente, nada mais que nomes significativos de confirmações. A única diferença entre ramificações locais e remotas é que as remotas são prefixadas com o remoteName/ Git desde o início, é uma leitura muito boa. Depois de entender como o Git funciona - e é realmente muito simples - tudo faz sentido.
Emil Lundberg

13
Muito obrigado pela explicação. Até agora não entendi que o Git foi projetado para que você não precisasse de um repositório central. Todo mundo sempre diz "DVCS" ao descrever o Git, mas como um programador relativamente novo, isso não significa nada para mim. Eu nunca vi um CVCS e também nunca trabalhei com um repositório remoto central quando colaborava com outras pessoas (por exemplo, Github), então até agora ainda não entendi o que tornou o Git especial.
Brian Peterson

7
Então, com base nisso, por que não é uma boa idéia buscar com um trabalho cron? Sempre é uma boa ideia manter uma cópia do controle remoto com o qual você está trabalhando na máquina local. Na verdade, sinto vontade de escrever um script que verifique se atualizei meu controle remoto nas últimas 24 horas e vinculei-o a um gancho udev para conexão à Internet.
Brian Peterson

24
Um dos motivos pelos quais não é uma boa ideia ter um trabalho cron: geralmente quando trabalho em um novo ticket ou em atualizações de uma filial, gosto de ver as alterações sendo buscadas. Se as alterações não ocorrerem durante uma busca, ficarei mais confiante em perguntar ao meu colega programador 'ei, você pressionou?'. Também tenho uma noção de quanto 'churn' no repositório desde a última vez que fui buscado. Isso também me ajuda a entender a quantidade e a velocidade das alterações atualmente sendo feitas neste repositório.
Michael Durrant

5
O @Nabheet Thing é que, o Git é orientado a conteúdo. Ele armazena dados apenas uma vez e aponta para eles várias vezes. É por isso que no Git, mesmo vários commits em cima de um original não afetam muito o tamanho do repositório, pois a maioria dos objetos é a mesma.
cst1992

890

Aqui está a imagem de Oliver Steele de como tudo se encaixa :

insira a descrição da imagem aqui

Se houver interesse suficiente, suponho que eu poderia atualizar a imagem para adicionar git clonee git merge...


156
Uma imagem atualizada com git clonee git mergeseria muito útil!
MEMark

20
Sim, adicione git merge- ele deve mostrar claramente que a mergechamada separada NÃO é a mesma que a chamada, pullporque pullé mesclada apenas do remoto e ignora as confirmações locais na filial local, que estão rastreando a filial remota que está sendo retirada.
precisa saber é o seguinte

12
Uma imagem vale mais que mil palavras! A imagem atualizada com fluxo de dados de clonagem e mesclagem está pronta em algum lugar? Algum outro fluxo de dados além do que já está no diagrama?
shikhanshu

10
@ Contango, adicione clone e mesclagem. Seria útil para iniciantes como eu.
aluga

11
Existem dois diagramas mostrando clone e mesclagem em outras respostas (abaixo) de th3sly e tharks passageiro.
Intotecho 12/08/16

488

Um dos casos de uso git fetché o seguinte: qualquer alteração na ramificação remota desde o último pull ... para que você possa verificar antes de fazer um pull real, o que pode alterar os arquivos na ramificação atual e na cópia de trabalho.

git fetch
git diff ...origin

Consulte: https://git-scm.com/docs/git-diff sobre a sintaxe de pontos duplos e triplos no comando diff


9
por que não git diff ..origin?
Erik Kaplun

3
origem do git diff e diff do git .. a origem parece funcionar, mas não é tão estranho ... coisas #
Marc Marc

19
@Compustretch Não deveria haver um espaço. git diff ...originé equivalente a git diff $(git-merge-base HEAD origin) origin(consulte a git diff [--options] <commit>...<commit> [--] [<path>…]seção kernel.org/pub/software/scm/git/docs/git-diff.html#_description ), que é diferente de git diff origin; git diff ...originé conceitualmente as alterações feitas origindesde que a ramificação atual ramificou origin, enquanto git diff origininclui também o reverso das alterações feitas na ramificação atual desde que ramificou origin.
Max Nanasy

2
nenhum dos comandos .. trabalharam para mim (no Windows), mas git diff origin/masterobras, como mencionado abaixo
Brian Burns

o mesmo aqui usando o git 2.0.0 no OSX. Nenhum desses comandos funcionou. Eles foram preteridos?
K.-Michael Aye

373

Me custou um pouco entender qual era a diferença, mas essa é uma explicação simples. masterno seu host local é uma filial.

Ao clonar um repositório, você busca o repositório inteiro no host local. Isso significa que naquele momento você tem um ponteiro de origem / mestre HEADe um mestre apontando para o mesmo HEAD.

Quando você começa a trabalhar e confirma, avança o ponteiro mestre para HEAD+ confirma. 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 git fetchisso, apenas buscará todas as alterações no repositório remoto ( GitHub ) e moverá o ponteiro de origem / mestre para HEAD. Enquanto isso, o mestre da filial local continuará apontando para onde está.
  • Se você fizer um git pull, ele buscará basicamente (como explicado anteriormente) e mesclará quaisquer novas alterações em sua ramificação principal e moverá o ponteiro para HEAD.

14
origem / mestre é uma filial local que é uma CÓPIA do mestre na origem. Ao buscar, você atualiza local: / origin / master. Uma vez que você realmente entenda que tudo no git é uma ramificação, isso faz muito sentido e é uma maneira muito poderosa de manter diferentes conjuntos de alterações, criar ramificações locais rápidas, mesclar e refazer e geralmente obtém muito valor da ramificação barata modelo.
cam8001

3
Ainda confuso. Eu pensei que git fetchera literalmente fazer o download das alterações no repositório remoto no seu repositório local, mas NÃO as confirme - ou seja, elas ainda precisam ser adicionadas / confirmadas no seu repositório local.
krb686

3
buscar apenas puxa de remoto / origem (github) para sua origem local. Mas não o mescla aos seus arquivos de trabalho reais. se você fizer um puxão ele vai buscar e a mesclagem para seus arquivos de trabalho actuais
Gerardo

223

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

insira a descrição da imagem aqui


18
Penso que a imagem demonstrou que também afeta o repo local. Ou seja, o Git pull é uma combinação de afetar o repositório local e a cópia de trabalho. No momento, parece que isso afeta apenas a cópia de trabalho.
nonopolarity

10
@ 太極 者 無極 而 生 Concordo - esta imagem é bastante enganadora, porque parece que git pullestá pulando a busca, o que obviamente é impreciso.
forresthopkinsa

9
Qual é a diferença entre um 'Repositório Local' e uma 'Cópia de Trabalho'? Os dois não são locais no computador?
theITvideos

1
Para que serve o git fetch? como ver que diferença existe no repositório local e na cópia de trabalho?
Vikash

2
@theITvideos Não, não é. Um repositório local é para onde o seu código vai (do repositório ativo) quando você confirma. (Vai para o repo remoto quando você pressiona).
Vikash

219

Brevemente

git fetché semelhante a, pullmas não é mesclado. isto é, busca atualizações remotas ( refse objects), mas seu local permanece o mesmo (ou seja, origin/masteré atualizado, mas masterpermanece o mesmo).

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

Mais

git clone clona um repositório.

git rebasesalva coisas do ramo atual que não está no ramo upstream em uma área temporária. Sua filial agora é a mesma de antes de você iniciar suas alterações. Portanto, git pull -rebasedesative as alterações remotas, rebobine sua filial local, reproduza as alterações por cima da filial atual, uma a uma, até que você esteja atualizado.

Além disso, git branch -amostrará 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 tampas git pull, git fetch, git clonee git rebase.

====

ATUALIZAR

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

  1. Atualize seu repositório local a partir do controle remoto (mas não mescle):

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

    git diff master origin/master 
    
  3. Se você estiver satisfeito com essas atualizações, mescle:

    git pull
    

Notas:

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

Na etapa 3: provavelmente é mais preciso (por exemplo, em um repositório que muda rapidamente) fazer um git rebase originaqui. Veja o comentário de Justin Ohms em outra resposta.

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


1
Parece-me que, se alguém quiser que o código local reflita "a dica", eles devem usar git clone. Eu coloquei a ponta entre aspas, como eu suponho que isso significaria tudo o mestre é e o que alguém faria "Download como zip" de github.com
Chris K

3
e se você não estiver satisfeito com as alterações depois de buscar o git? o que fazer a seguir?
24715 Kugutsumen

Seu parágrafo sobre rebase era exatamente o que eu estava procurando. Toda a ideia de zerar tudo, atualizar do controle remoto e reproduzir novamente as alterações em cima das confirmações anteriores que aconteceram enquanto você estava trabalhando. Explicação perfeita, assumindo que está correto. ;)
coblr

178
git-pull - Busque e mescla com outro repositório ou uma filial local
SINOPSE

git pull…
DESCRIÇÃO

Executa git-fetch com os parâmetros fornecidos e chama git-merge para mesclar o 
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> a ser puxado
do repositório local - isso é útil ao mesclar ramificações locais 
no ramo atual.

Observe também que as opções destinadas ao próprio git-pull e ao git-merge subjacente 
deve ser fornecido antes das opções destinadas ao git-fetch.

Você poderia puxar se quiser que as histórias sejam mescladas e buscá-las se você apenas 'quiser o codez', pois alguma pessoa está etiquetando alguns artigos por aqui.


5
Muito interessante, mas não consigo ver um caso de uso em que você queira "apenas o código". E o que acontece com o seu código quando você busca? É apagado? O que acontece com as mudanças remotas? Como ele entra no seu repositório sem apagar seu código se você não mescla?
e-satis

11
@ e-satis: A filial remota também é armazenada localmente na sua máquina. Portanto, quando você faz git fetchisso, busca alterações no repositório e atualiza sua filial remota local. Não afeta sua filial local, que rastreia a filial remota local, portanto não afeta sua cópia de trabalho. Agora, quando você faz um, mergeele mescla as alterações buscadas com sua filial local.
31511 Jeffersonveon

Um caso de uso simples para o comando buscar: executar operações demoradas que envolvem confirmações recentes de outras pessoas, como uma mesclagem ou uma revisão de código, acessando apenas seu repositório local atualizado sem requisitos de conectividade de rede, porque você usou a busca anteriormente para baixar tudo o que você precisa rapidamente (por exemplo, enquanto você está visitando outro desenvolvedor e conectado à rede de outro repositório). O comando pull faria o download dos mesmos commits, mas a mesclagem executada pode ser indesejável.
Lorenzo Gatti

163

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

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

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

35
Você provavelmente deseja pular a solicitação e apenas fazer uma "origem de rebase do git" como a última etapa desde que você já buscou as alterações. O motivo é que alguém poderia ter promovido alterações no tempo desde que você fez a busca e elas não teriam sido encontradas na qual você fez a revisão de diff.
Justin Ohms

158

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

É muito importante observar que git pullele se fundirá automaticamente, quer você goste ou não . Obviamente, isso pode resultar em conflitos de mesclagem. Digamos que seu controle remoto seja origine seu ramo seja master. Se git diff origin/masterantes de puxar, você deve ter alguma idéia de possíveis conflitos de mesclagem e preparar sua filial local adequadamente.

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

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

Se você se encontra nessa situação, pode ser tentado git pull --rebase. A menos que você realmente saiba o que está fazendo, eu desaconselharia isso. Este aviso é da manpágina para git-pull, versão 2.3.5:

Este é um modo de operação potencialmente perigoso. Ele reescreve o histórico, o que não é um bom presságio quando você já o publicou. Não use esta opção, a menos que você tenha lido git-rebase (1) cuidadosamente.


2
@JustinOhms Se git pull --rebasenão é a coisa certa em uma situação específica, é certo se for feita em duas etapas? Se é a coisa certa a fazer, qual é o benefício extra de fazê-lo em duas etapas?
Kaz

@ Kaz - porque o rebase não é automático. A busca das alterações primeiro permite que você faça a chamada de julgamento. Não resolve o problema com o histórico de rebaseamento que você já enviou. Isso permitirá que você veja se é seguro refazer as alterações ainda não enviadas.
Justin Ohms

2
@JustinOhms Como você decidiria se é seguro refazer as alterações? Eu tentaria apenas o git rebase e retornaria se isso fizesse uma bagunça; nesse caso, eu também poderia fazer o git pull --rebase. Mas talvez você tenha alguma outra maneira?
Kaz

3
O @KaZ gitk permite que você veja a estrutura de ramificação visualmente. Ele mostrará a posição da sua cabeça local, controles remotos e estruturas de seu ramo em relação ao que você buscou. Dessa forma, você pode garantir que você não está reestruturando as alterações buscadas com base em um ancestral anterior ao que você já enviou aos seus remotos.
Justin Ohms 28/05

Use rebasequando você estiver trabalhando em uma filial local ainda não enviada por push. Se você estiver trabalhando em uma filial que existe no controle remoto, rebasepode resultar em alguns problemas desagradáveis, portanto, você deve preferir um regular merge.
Justus Romijn

151

OK , aqui estão algumas informações sobre git pulle git fetch, para que você possa entender as diferenças reais ... em poucas palavras simples, a busca obtém os dados mais recentes, mas o código não muda e não mexe com o código da filial local atual, mas puxe get o código muda e mescla-o à sua filial local, continue lendo para obter mais detalhes sobre cada um:

busca do git

Ele irá baixar todos os refs e objetos e quaisquer novas agências para o seu repositório local ...

Busque ramificações e / ou tags (coletivamente, "refs") de um ou mais outros repositórios, juntamente com os objetos necessários para completar seus históricos. As ramificações de rastreamento remoto são atualizadas (consulte a descrição abaixo para obter formas de controlar esse comportamento).

Por padrão, qualquer tag que aponte para os históricos que estão sendo buscados também é buscada; o efeito é buscar tags que apontam para os ramos nos quais você está interessado. Esse comportamento padrão pode ser alterado usando as opções --tags ou --no-tags ou configurando remote..tagOpt. Usando um refspec que busca tags explicitamente, você pode buscar tags que não apontam para ramificações nas quais você também está interessado.

O git fetch pode buscar em um único repositório ou URL nomeado ou em vários repositórios de uma só vez, se for fornecido e houver controles remotos. entrada no arquivo de configuração. (Veja git-config 1 ).

Quando nenhum controle remoto é especificado, por padrão, o controle remoto de origem será usado, a menos que haja um ramo upstream configurado para o ramo atual.

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


puxão

Ele aplicará as alterações de remoto para o ramo atual no local ...

Incorpora alterações de um repositório remoto na ramificação atual. Em seu modo padrão, git pull é uma abreviação de git fetch seguida por git merge FETCH_HEAD.

Mais precisamente, o git pull executa o git fetch com os parâmetros fornecidos e chama o git merge para mesclar as cabeças de ramificação recuperadas na ramificação atual. Com --rebase, ele executa git rebase em vez de git merge.

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

Os valores padrão para e são lidos nas configurações "remota" e "mesclada" da ramificação atual, conforme definido pelo git-branch --track.


Também crio o visual abaixo para mostrar como git fetche git pulltrabalhando juntos ...

puxar git e buscar git


10
Se você gosta da imagem, em seguida, dê uma olhada na folha de git fraude, que é o mesmo tipo de coisas para todos git comandos ... ndpsoftware.com/git-cheatsheet.html
Tom

3
O clone também não afeta o repositório local (copiando todo o histórico do controle remoto)?
21418 Tom Tomedo

135

insira a descrição da imagem aqui

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

git fetchbasta "baixar" as alterações do controle remoto para o seu repositório local. git pullbaixa as alterações e as mescla em sua filial atual. "No modo padrão, git pullé uma abreviação para git fetchseguido por git merge FETCH_HEAD".


18
Pessoas, clique no link para interagir com as diferentes colunas. Esta folha de dicas é o melhor recurso que eu já vi para entender completamente as diferenças entre cada comando.
Luisa Carrión

Esta resposta deve ir para o topo
Tessaracter 26/10/19

126

Bônus:

Ao falar sobre puxar e buscar nas respostas acima, gostaria de compartilhar um truque interessante,

git pull --rebase

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

Antes de enviar suas novas confirmações para o servidor, tente este comando e ele sincronizará automaticamente as alterações mais recentes do servidor (com uma busca + mesclagem) e colocará sua confirmação no topo do log do git. Não precisa se preocupar com puxar / mesclar manualmente.

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


4
Boa dica, embora valha a pena mencionar para os novos usuários do git que rebase modificam os hashes de confirmação (eu achei isso surpreendente vindo do subversion).
AlexMA # 20/16

1
Você pode explicar qual é a diferença entre git pulle git pull --rebase?
shaijut

2
Veja o aviso

118

Eu gosto de ter alguma representação visual da situação para entender essas coisas. Talvez outros desenvolvedores também gostem de vê-lo, então aqui está minha adição. Não tenho certeza de que tudo esteja correto, 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 das principais vantagens de obter um espelho do controle remoto são:

  • Desempenho (percorra todas as confirmações e mensagens sem tentar comprimir pela rede)
  • Comentários sobre o estado do seu repositório local (por exemplo, eu uso o SourceTree da Atlassian, que fornecerá uma lâmpada indicando se estou comprometido com antecedência ou atrasado em comparação com a origem. Essas informações podem ser atualizadas com um GIT FETCH).

git pullTambém não realiza uma mesclagem, ou seja, indo até a cópia de trabalho?
Kamiel Wanrooij 24/03

Bom ponto, sim, ele colocará todas as alterações em sua cópia de trabalho e você poderá enviá-lo para o repositório local. Vou atualizar o visual.
precisa

@JustusRomijn O pull também não atualiza o repositório local? Não deveria haver um asterisco entre os asteriscos de origem e cópia de trabalho?
user764754

2
@ user764754 Quando você puxa, sua cópia de trabalho recebe as alterações (também pode haver alguns conflitos que talvez você precise resolver). Você ainda precisa enviá-lo para o seu repositório local.
Justus Romijn

@JustusRomijn: Obrigado pela ilustração. Seria ótimo se você pudesse tornar o diagrama mais abrangente, ilustrando os efeitos de operações como redefinição e seleção de cereja nos estados do repositório.
jith912

106

Eu lutei com isso também. Na verdade, cheguei aqui com uma pesquisa no google exatamente da mesma pergunta. A leitura de todas essas respostas finalmente pintou uma imagem na minha cabeça e eu decidi tentar analisar o estado dos 2 repositórios e 1 sandbox e ações executadas ao longo do tempo enquanto assistia a versão deles. Então aqui está o que eu criei. Por favor, me corrija se eu errei em algum lugar.

Os três repositórios 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.


Não é tão difícil de ler: as caixas representam o status de um repo, que em cada linha muda no tempo da esquerda para a direita após a operação relatada na linha 2 da caixa. Os rótulos R0n são marcas no git, e uma marca com um + é ainda um item não-solicitado. O Sanbox é usado para sua pasta de trabalho, que é diferente da pasta de recompra, onde as coisas confirmadas são armazenadas.
user1708042

96

A diferença entre o GIT Fetch e o GIT Pull pode ser explicada no seguinte cenário: (Lembre-se de que as imagens falam mais alto que as palavras !, forneci representação pictórica)

Vamos dar um exemplo de que você está trabalhando em um projeto com os membros da sua equipe. Portanto, eles serão um ramo principal do projeto e todos os colaboradores deverão enviá-lo para seu próprio repositório local e, em seguida, trabalhar nesse ramo local para modificar / adicionar módulos e retornar ao ramo principal.

Portanto, o estado inicial dos dois ramos quando você bifurcou o projeto principal em seu repositório local será assim- ( A, Be Cos Módulos já estão concluídos do projeto)

insira a descrição da imagem aqui

Agora, você já começou a trabalhar no novo módulo (suponho D) e quando você tiver concluído o Dmódulo que deseja empurrá-lo para o ramo principal, mas enquanto isso o que acontece é que um de seus companheiros de equipe desenvolveu novo módulo E, Fe modificado C.
Então agora o que aconteceu é que seu repositório local está atrasado em relação ao progresso original do projeto e, portanto, o envio de suas alterações para o ramo principal pode levar a conflitos e causar Dmau funcionamento do seu Módulo .

insira a descrição da imagem aqui

Para evitar esses problemas e trabalhar em paralelo com o progresso original do projeto, são duas maneiras:

1. Git Fetch - Isso fará o download de todas as alterações feitas no projeto de origem / filial principal que não estão presentes na filial local. E aguardará o comando Git Merge para aplicar as alterações que foram buscadas no seu Repositório ou ramo.

insira a descrição da imagem aqui

Agora você pode monitorar cuidadosamente os arquivos antes de mesclá-los ao seu repositório. E você também pode modificar, Dse necessário, devido a Modificado C.

insira a descrição da imagem aqui

2. Git Pull - Isso atualizará sua ramificação local com a ramificação origem / principal, ou seja, na verdade, o que faz é uma combinação de Git Fetch e Git mescladas uma após a outra. Mas isso pode causar conflitos, por isso é recomendável usar o Git Pull com uma cópia limpa.

insira a descrição da imagem aqui


1
se você pudesse alterar 'Main Branch' para 'Repo Remote', seria uma ótima resposta.
Qibiron Quem

87

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 na sua máquina local. Caso contrário, o código da máquina local não seria alterado sem mesclagem.

Portanto, no Git Gui, quando você busca, você precisa mesclar os dados. A busca em si não fará as alterações de código no seu local. Você pode verificar isso quando 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.


3
Eu prefiro dizer git pull == git fetch + git merge:)
melvynkim

2
Masgit pull --rebase = git fetch + git rebase
Tino

83

git fetchtransfere o código do servidor remoto para suas ramificações de rastreamento em seu repositório local. Se seu controle remoto é nomeado origin(o padrão), em seguida, esses ramos estará dentro origin/, por exemplo origin/master, origin/mybranch-123, etc. Estes não são seus ramos atuais, eles são locais cópias desses ramos do servidor.

git pullfaz um git fetchmas também mescla o código da ramificação de rastreamento em sua versão local atual dessa ramificação. Se você ainda não está pronto para essas mudanças, git fetchprimeiro.


78

git fetchirá recuperar filiais remotas de modo que você pode git diffou git mergelos com o ramo atual. git pullexecutará a busca no brach remoto rastreado pela ramificação atual e mesclará o resultado. Você pode usar git fetchpara verificar se há atualizações na filial remota sem a necessidade de mesclá-las à filial local.


73

Git Fetch

Você faz o download das alterações na ramificação local desde a origem até a busca. Buscar solicita ao repositório remoto todas as confirmações feitas por outras pessoas, mas você não o possui no repositório local. A busca baixa esses commits e os adiciona ao repositório local.

Git Merge

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

Git Pull

A busca e a mesclagem são executadas juntas o suficiente para que um comando que combine os dois pull seja criado. Pull faz uma busca e, em seguida, uma mesclagem para adicionar as confirmações baixadas em sua filial local.


51

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

git pull puxa de uma ramificação remota e a mescla.

git fetch busca apenas a partir da ramificação remota, mas não é mesclada

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


1
E também não ajuda se o git pensa que você está atrasado por cometer e pode "avançar rapidamente", o que acabei terminando rm -rftudo e recomeçando. Git estúpido, por favor, deixe-me atualizar para que eu possa voltar ao trabalho?
Chris K

47

Em termos simples, se você estava prestes a subir em um avião sem conexão com a Internet ... antes de partir, você poderia simplesmente fazê-lo git fetch origin <master>. Seria buscar todas as alterações no seu computador, mas mantê-lo separado do seu desenvolvimento / espaço de trabalho local.

No avião, você pode fazer alterações no espaço de trabalho local e mesclá-lo com o que buscou e resolver possíveis conflitos de mesclagem, tudo sem uma conexão com a Internet. E, a menos que alguém tenha feito novas alterações conflitantes no repositório remoto, depois que você chegar ao destino, você fará git push origin <branch>o café.


Neste incrível tutorial Atlassian :

O git fetchcomando baixa confirmações, arquivos e refs de um repositório remoto no seu repositório local.

Buscar é o que você faz quando deseja ver o que todo mundo está trabalhando. É semelhante à atualização do SVN, pois permite ver como o histórico central progrediu, mas não o força a realmente mesclar as alterações no seu repositório. O Git isola o conteúdo buscado do conteúdo local existente , não tem absolutamente nenhum efeito no seu trabalho de desenvolvimento local . O conteúdo buscado deve ser retirado explicitamente usando o git checkoutcomando Isso torna a busca de uma maneira segura de revisar confirmações antes de integrá-las ao seu repositório local.

Ao fazer o download de conteúdo de um repositório remoto, git pulle git fetchcomandos estão disponíveis para realizar a tarefa. Você pode considerar git fetcha versão 'segura' dos dois comandos. Ele fará o download do conteúdo remoto, mas não atualizará o estado de trabalho do repositório local, deixando intacto o trabalho atual. git pullé a alternativa mais agressiva, ele fará o download do conteúdo remoto para a ramificação local ativa e executará imediatamente git mergepara criar uma confirmação de mesclagem para o novo conteúdo remoto. Se houver alterações pendentes em andamento, isso causará conflitos e iniciará o fluxo de resolução de conflitos de mesclagem.


Com git pull:

  • Você não recebe nenhum isolamento.
  • Isso afeta o seu desenvolvimento local.
  • Não precisa ser explicitamente verificado. Porque implicitamente faz a git merge.
  • Basicamente, NÃO é seguro. É agressivo.
  • Diferente de git fetchonde isso afeta apenas o seu .git/refs/remotes, o git pull afetará tanto o seu .git/refs/remotes como .git/refs/heads/

Hmmm ... então, se não estou atualizando a cópia de trabalho git fetch, onde estou fazendo alterações? Onde o Git busca armazenar os novos commits?

Ótima pergunta. Coloca em algum lugar isolado da sua cópia de trabalho. Mas de novo onde? Vamos descobrir.

No diretório do seu projeto (ou seja, onde você executa seus gitcomandos), faça:

  1. ls. Isso mostrará os arquivos e diretórios. Nada legal, eu sei.

  2. Agora faça ls -a. Isto irá mostrar os arquivos de ponto , ou seja, os arquivos começando com .então você vai ser capaz de ver um diretório chamado: .git.

  3. Faça cd .git. Obviamente, isso mudará seu diretório.
  4. Agora vem a parte divertida; faça ls. Você verá uma lista de diretórios. Estamos procurando refs. Faça cd refs.
  5. É interessante ver o que está dentro de todos os diretórios, mas vamos nos concentrar em dois deles. headse remotes. Use cdpara verificar dentro deles também.
  6. Tudo o git fetch que você fizer atualizará itens no /.git/refs/remotesdiretório Não atualizará nada no /.git/refs/headsdiretório.
  7. Qualquer git pull um primeiro fará os git fetchitens de atualização no /.git/refs/remotesdiretório, depois se fundirá com o seu local e depois mudará a cabeça dentro do /.git/refs/headsdiretório.

Uma resposta relacionada muito boa também pode ser encontrada em Onde o 'git fetch' se coloca? .

Além disso, procure "Notação de barra" na publicação das convenções de nomenclatura do ramo Git . Ajuda a entender melhor como o Git coloca as coisas em diretórios diferentes.


Para ver a diferença real

Apenas faça:

git fetch origin master
git checkout master

Se o mestre remoto foi atualizado, você receberá uma mensagem como esta:

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Se você não fez fetche acabou de fazer git checkout master, seu git local não saberia que existem dois commits adicionados. E diria apenas:

Already on 'master'
Your branch is up to date with 'origin/master'.

Mas isso está desatualizado e incorreto. É porque o git fornecerá feedback apenas com base no que ele sabe. É inconsciente de novos commits que ainda não foram eliminados ...


Existe alguma maneira de ver as novas alterações feitas no controle remoto enquanto trabalha na filial localmente?

Alguns IDEs (por exemplo, Xcode) são super inteligentes e usam o resultado de a git fetche podem anotar as linhas de código que foram alteradas no ramo remoto do seu ramo de trabalho atual. Se essa linha tiver sido alterada por alterações locais e ramificação remota, essa linha será anotada em vermelho. Este não é um conflito de mesclagem. É um potencial conflito de mesclagem. É um heads-up que você pode usar para resolver o futuro conflito de mesclagem antes de fazer a git pullpartir da ramificação remota.

insira a descrição da imagem aqui


Dica divertida:

Se você buscou uma ramificação remota, por exemplo:

git fetch origin feature/123

Então isso entraria no diretório de controles remotos. Ainda não está disponível no seu diretório local. No entanto, simplifica seu checkout para essa filial remota com DWIM (faça o que eu quero dizer):

git checkout feature/123

você não precisa mais fazer:

git checkout -b feature/123 origin/feature/123

Para mais informações, leia aqui


1
Eu gosto desta resposta
Kid_Learning_C 16/05/19

44

O Git permite que as confirmações cronologicamente mais antigas sejam aplicadas após as confirmações mais recentes. Por esse motivo, o ato de transferir confirmações entre repositórios é dividido em duas etapas:

  1. A cópia de novas confirmações da ramificação remota para cópia dessa ramificação remota dentro do repositório local.

    (operação de recompra a recompra) master@remote >> remote/origin/master@local

  2. Integrando novas confirmações à filial local

    (operação de repo) remote/origin/master@local >> master@local

Há duas maneiras de executar a etapa 2. Você pode:

  1. Bifurque a ramificação local após o último ancestral comum e inclua novas confirmações paralelas às confirmações exclusivas do repositório local, finalizadas pela fusão da confirmação e fechando a bifurcação.
  2. Inserir novas confirmações após o último ancestral comum e reaplicar confirmações exclusivas ao repositório local.

Na gitterminologia, a etapa 1 é git fetch, a etapa 2 é git mergeougit rebase

git pullé git fetchegit merge


37

O Git obtém a ramificação da versão mais recente do controle remoto para o local usando dois comandos:

  1. git fetch: O Git obterá a versão mais recente do remoto para o local, mas não será mesclada automaticamente.      git fetch origin master git log -p master..origin/master git merge origin/master

         Os comandos acima significam que baixe a versão mais recente da ramificação principal da origem da ramificação mestre remota para a origem. E, em seguida, compara o ramo mestre local e o ramo mestre de origem. Finalmente, mesclar.

  2. git pull: O Git obterá a versão mais recente do controle remoto e se unirá ao local.

        git pull origin master

         O comando acima é equivalente a git fetche git merge. Na prática, git fetchtalvez mais seguro, porque antes da mesclagem podemos ver as alterações e decidir se a mescla.


37

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

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

git fetchatualiza sua cópia local do repositório remoto. Por exemplo, se o seu repositório remoto for GitHub - convém buscar as alterações feitas no repositório remoto na sua cópia local do repositório remoto. Isso permitirá que você execute 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 pullvocê fará o git fetchprimeiro para atualizar a cópia local do repositório remoto e, em seguida, mesclará as alterações no seu próprio repositório de código e possivelmente na sua cópia de trabalho.


35

git pull == (busca do git + fusão do git)

O git fetch não muda para as ramificações locais.

Se você já possui um repositório local com uma configuração remota para o projeto desejado, pode pegar todas as ramificações e tags do controle remoto existente usando o git fetch. ... A busca não faz nenhuma alteração nas ramificações locais, portanto, você precisará mesclar uma ramificação remota com uma ramificação local emparelhada para incorporar as alterações de nova busca. do github


34

Tentando ser claro e simples.

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


33

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

insira a descrição da imagem aqui

aqui,

git pull  

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

mas em ,

busca do git

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

por exemplo: eu vou buscar no servidor master e rebase no meu mestre local.

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

git pull origin master

aqui origem é o seu repo master remoto é sua filial

2) git fetch (necessidade de rebase manualmente):

git fetch origin master

ele buscará as alterações do servidor de origem. e ele estará no seu local até que você o refaça por conta própria. precisamos corrigir conflitos manualmente verificando códigos.

git rebase origin/master

isso irá refazer o código em local. antes disso, verifique se você está no ramo certo.


Gráfico bonito, mas você pode explicar por que usa "rebase" quando o gráfico diz "mesclar".
Guntram Blohm apoia Monica

2
A mesclagem representará outra confirmação de ramificação e produzirá uma nova confirmação que contém confirmações como referência. mas rebase irá replicar commits de um outro ramo que costuma criar novo commit em vez do que replicar
Mohideen bin Mohammed

33

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

O comando git fetch atualiza sua cópia local, obtendo dados do repositório remoto. A razão pela qual precisamos disso é porque outra pessoa pode ter feito algumas alterações no código e você deseja manter-se atualizado.

O comando git pulltraz as alterações no repositório remoto para onde você mantém seu próprio código. Normalmente, git pullisso é feito primeiro 'git fetch' para atualizar a cópia local do repositório remoto e, em seguida, mescla as alterações no seu próprio repositório de código e possivelmente na sua cópia de trabalho.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.