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




vs branch (25)

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 ?


Answers

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

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


A diferença entre o GIT Fetch e o GIT Pull pode ser explicada com o seguinte cenário: (Tendo em mente que as imagens falam mais alto que as palavras !, eu forneci representação pictórica)

Vamos dar um exemplo de que você está trabalhando em um projeto com os membros de sua equipe. Então, o seu será um ramo principal do projeto e todos os contribuidores devem bifurcá-lo para o seu próprio repositório local e, em seguida, trabalhar neste ramo local para modificar / adicionar módulos e, em seguida, empurrar de volta para o ramo principal.

Então, Estado inicial dos dois ramos quando você bifurcada o projeto principal em seu repositório local será como this- ( A, Be Csão módulos já concluída do projeto)

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 o seu repositório local está atrasado em relação ao progresso original do projeto e, portanto, pressionar as alterações para o ramo principal pode gerar conflitos e causar Dmau funcionamento do Módulo .

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

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

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

2. Git Pull - Isto irá atualizar o seu branch local com a origem / branch principal, isto é, na verdade, o que ele faz é uma combinação do Git Fetch e do Git, mesclar um após o outro. Mas isso pode causar conflitos, por isso é recomendado usar o Git Pull com uma cópia limpa.


git pull == (git fetch + git merge)

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

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


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


OK , 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, o fetch obtém os dados mais recentes, mas não o código muda e não vai mexer no seu código de ramificação local atual , mas puxar obter as alterações de código e mesclar o seu ramo local, continue a ler para obter mais detalhes sobre cada um:

git fetch

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

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

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

git fetch pode buscar a partir de um único repositório nomeado ou URL, ou de vários repositórios de uma vez, se for dado e houver um controle remoto. entrada no arquivo de configuração. (Veja git-config 1 ).

Quando nenhum controle remoto é especificado, por padrão, o remoto de origem será usado, a menos que haja uma ramificação upstream configurada para a ramificação atual.

Os nomes das referências que são buscadas, juntamente com os nomes de 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.

git pull

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

Incorpora as alterações de um repositório remoto no ramo atual. Em seu modo padrão, o git pull é uma forma abreviada de buscar o git seguido por git merge FETCH_HEAD.

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

deve ser o nome de um repositório remoto conforme transmitido para 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 refs 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.

Valores padrão para e são lidos a partir da configuração "remote" e "merge" para a ramificação atual, conforme definido por git-branch --track.

Eu também crio o visual abaixo para mostrar como git fetch e git pull trabalham juntos ...

1


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.


É 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.


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.


git pull = git fetch + git merge 

O Git obtém a ramificação da última versão do 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á automaticamente mesclada. git fetch origin master git log -p master..origin/master git merge origin/master

    Os comandos acima significam que o download da última versão da ramificação principal de origem do remoto para a ramificação mestre de origem. 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 entrará no local.

    git pull origin master

    O comando acima é o 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 devemos mesclar.



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.


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.


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 ."


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.


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.


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).

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.


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.


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.


  • Quando você usa pull , o Git tenta fazer seu trabalho automaticamente por você. É sensível ao contexto , então o Git irá mesclar quaisquer commits puxados na ramificação em que você está trabalhando atualmente. pull automaticamente mescla os commits sem permitir que você os revise primeiro . Se você não gerencia suas filiais de perto, você pode entrar em conflitos freqüentes.

  • Quando você fetch , o Git reúne qualquer confirmação da ramificação de destino que não existe em sua ramificação atual e a armazena em seu repositório local . No entanto, ele não os mescla com sua ramificação atual . Isto é particularmente útil se você precisa manter seu repositório atualizado, mas está trabalhando em algo que pode quebrar se você atualizar seus arquivos. Para integrar os commits em seu branch master, você usa merge .


git fetchobtém 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 do ramo de rastreamento em sua versão local atual desse ramo. Se você ainda não está preparado para essas mudanças, apenas git fetchprimeiro.


Um caso de uso de git fetch é que o seguinte informará quaisquer alterações na ramificação remota desde o último pull ... para que você possa verificar antes de fazer um pull real, o que poderia alterar os arquivos na ramificação atual e na cópia de trabalho.

git fetch
git diff ...origin

git clean -df

Limpa a árvore de trabalho removendo recursivamente arquivos que não estão sob controle de versão, iniciando no diretório atual.

-d : remove diretórios não rastreados além de arquivos não rastreados

-f : Force (pode não ser necessário dependendo da configuração clean.requireForce )

Execute o git help clean para ver o manual







git git-pull git-fetch