it-swarm.dev

Qual è la differenza tra "git pull" e "git fetch"?

Nota del moderatore: Dato che questa domanda ha già avuto sessantasette risposte inviate ad essa (alcune cancellate), considera se staicontribuendo con qualcosa di nuovoprima pubblicarne un altro.

Quali sono le differenze tra git pull e git fetch?

10728
pupeno

Nei termini più semplici, git pull fa un git fetch seguito da un git merge.

Puoi fare un git fetch in qualsiasi momento per aggiornare i tuoi rami di tracciamento remoto sotto refs/remotes/<remote>/.

Questa operazione non cambia mai nessuno dei tuoi rami locali sotto refs/heads, ed è sicuro di fare senza modificare la tua copia di lavoro. Ho persino sentito parlare di persone che eseguono periodicamente git fetch in un cron job in background (anche se non consiglierei di farlo).

Un git pull è ciò che si farebbe per aggiornare un ramo locale con la sua versione remota, aggiornando anche gli altri rami di tracciamento remoto.

Documentazione Git: git pull

8962
Greg Hewgill
  • Quando usi pull, Git prova a fare automaticamente il tuo lavoro per te. È sensibile al contesto , quindi Git unirà tutti i commit tirati nel ramo in cui stai attualmente lavorando. pull unisce automaticamente i commit senza che tu possa prima controllarli . Se non gestisci da vicino le tue filiali, potresti incontrare frequenti conflitti.

  • Quando tu fetch, Git raccoglie qualsiasi commit dal ramo di destinazione che non esiste nel tuo ramo corrente e li memorizza nel tuo repository locale . Tuttavia, non li unisce con il ramo attuale . Ciò è particolarmente utile se è necessario mantenere aggiornato il repository, ma sta lavorando su qualcosa che potrebbe interrompersi se si aggiornano i file. Per integrare i commit nel tuo ramo master, usi merge.

1969
Mouna Cheikhna

È importante confrontare la filosofia del design di git con la filosofia di uno strumento di controllo del codice sorgente più tradizionale come SVN.

Subversion è stato progettato e realizzato con un modello client/server. Esiste un unico repository che è il server, e diversi client possono recuperare il codice dal server, lavorarci sopra, quindi reinserirlo nel server. Il presupposto è che il client possa sempre contattare il server quando è necessario eseguire un'operazione.

Git è stato progettato per supportare un modello più distribuito senza la necessità di un repository centrale (sebbene tu possa sicuramente usarne uno se lo desideri). Anche git è stato progettato in modo che il client e il "server" non debbano essere online allo stesso tempo. Git è stato progettato in modo che le persone su un link inaffidabile possano scambiare il codice via email, anche. È possibile lavorare completamente disconnesso e masterizzare un CD per lo scambio di codice tramite git.

Per supportare questo modello git gestisce un repository locale con il proprio codice e anche un repository locale aggiuntivo che rispecchia lo stato del repository remoto. Mantenendo una copia del repository remoto localmente, git può capire le modifiche necessarie anche quando il repository remoto non è raggiungibile. Successivamente, quando è necessario inviare le modifiche a qualcun altro, git può trasferirle come una serie di modifiche da un punto nel tempo noto al repository remoto.

  • git fetch è il comando che dice "porta la mia copia locale dell'archivio remoto aggiornata". 

  • git pull dice "porta le modifiche nel repository remoto a dove tengo il mio codice".

Normalmente git pull esegue ciò git fetch per aggiornare la copia locale dell'archivio remoto e quindi unire le modifiche nel proprio repository di codice e possibilmente nella propria copia di lavoro.

Il take away è da tenere presente che ci sono spesso almeno tre copie di un progetto sulla tua workstation. Una copia è il tuo repository con la tua cronologia di commit. La seconda copia è la tua copia di lavoro in cui stai modificando e costruendo. La terza copia è la tua copia "cache" locale di un repository remoto.

1104
MikeD

Ecco L'immagine di Oliver Steele di come tutto si combina perfettamente :

enter image description here

Se c'è interesse sufficiente, suppongo di poter aggiornare l'immagine per aggiungere git clone e git merge... 

744
Contango

Un caso di utilizzo di git fetch è che quanto segue ti indicherà eventuali cambiamenti nel ramo remoto dall'ultima estrazione ... in modo da poter controllare prima di eseguire un pull effettivo, che potrebbe cambiare i file nel ramo corrente e nella copia di lavoro.

git fetch
git diff ...Origin
446
mepster

Mi è costato un po 'capire qual era la differenza, ma questa è una spiegazione semplice. master nel tuo localhost è un ramo.

Quando cloni un repository, recuperi l'intero repository all'host locale. Ciò significa che in quel momento hai un puntatore origine/master per HEAD e il master che punta allo stesso HEAD.

quando inizi a lavorare e ti impegni, fai avanzare il puntatore master su HEAD + i tuoi commit. Ma il puntatore Origine/master sta ancora puntando a quello che era quando hai clonato.

Quindi la differenza sarà:

  • Se fai un git fetch, recupererà tutte le modifiche nel repository remoto ( GitHub ) e sposterà il puntatore Origin/master su HEAD. Nel frattempo il tuo supervisore di ramo locale continuerà a indicare dove si trova.
  • Se fai un git pull, lo farà fondamentalmente fetch (come spiegato in precedenza) e unirà tutte le nuove modifiche al tuo ramo master e sposterà il puntatore a HEAD.
351
Gerardo

A volte una rappresentazione visiva aiuta.

 enter image description here

195
thedarkpassenger

Briefly

git fetch è simile a pull ma non si unisce. cioè recupera aggiornamenti remoti (refs e objects) ma il tuo locale rimane lo stesso (cioè Origin/master viene aggiornato ma master rimane lo stesso).

git pull abbassa da un telecomando e si fonde all'istante.

Di Più

git clone clona un repo.

git rebase salva elementi dal ramo corrente che non si trova nel ramo upstream in un'area temporanea. Il tuo ramo è ora lo stesso di prima di iniziare le modifiche. Pertanto, git pull -rebase eseguirà il pull down delle modifiche remote, riavvolgerà il ramo locale, riprodurrà le modifiche nella parte superiore del ramo corrente una alla volta fino a quando non sarai aggiornato.

Inoltre, git branch -a ti mostrerà esattamente cosa sta succedendo a tutte le tue filiali, locali e remote.

Questo post del blog è stato utile:

La differenza tra git pull, git fetch e git clone (e git rebase) - Mike Pearce

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

====

AGGIORNARE

Ho pensato di aggiornarlo per mostrare come lo utilizzeresti in pratica. 

  1. Aggiorna il repository locale dal telecomando (ma non unire):

    git fetch 
    
  2. Dopo aver scaricato gli aggiornamenti, vediamo le differenze:

    git diff master Origin/master 
    
  3. Se sei soddisfatto di questi aggiornamenti, quindi unisci:

    git pull
    

Gli appunti:

Al punto 2: Per maggiori informazioni sulle differenze tra locale e telecomandi, vedi: Come confrontare un ramo git locale con il suo ramo remoto?

Nel passaggio 3: è probabilmente più accurato (ad esempio su un repository in rapida evoluzione) per eseguire un git rebase Origin qui. Vedi Commento @Justin Ohms in un'altra risposta.

Vedi anche: http://longair.net/blog/2009/04/16/git-fetch-and-merge/

189
Snowcrash
 git-pull - Recupera e fonde con un altro repository o ramo locale 
 SYNOPSIS 

 git pull ... 
 DESCRIPTION 

 Esegue git-fetch con i parametri dati, e chiama git-merge per unire le testine 
 recuperate nel ramo corrente. Con --rebase, chiama git-rebase 
 Invece di git-merge .

 Si noti che è possibile utilizzare. (directory corrente) come <repository> per estrarre 
 dal repository locale - questo è utile quando si uniscono i rami locali 
 nel ramo corrente .

 Si noti inoltre che le opzioni hanno significato per git-pull stesso e sotto git-merge 
 deve essere dato prima delle opzioni intese per git-fetch .

Tireremmo se volete che le storie vengano unite, se doveste semplicemente "volere il codez", come qualcuno ha etichettato alcuni articoli qui.

164
Vinko Vrsalovic

È possibile recuperare da un repository remoto, vedere le differenze e quindi tirare o unire.

Questo è un esempio per un repository remoto chiamato Origin e un ramo chiamato master che tiene traccia del ramo remoto Origin/master:

git checkout master                                                  
git fetch                                        
git diff Origin/master
git rebase Origin master
151
Antonio Bardazzi

La risposta breve e facile è che git pull è semplicemente git fetch seguito da git merge.

È molto importante notare che git pull si si unirà automaticamente se ti piace o meno. Ciò potrebbe, naturalmente, causare conflitti di fusione. Supponiamo che il tuo remoto sia Origin e che il tuo ramo sia master. Se git diff Origin/master prima di estrarre, dovresti avere qualche idea di potenziali conflitti di fusione e potresti preparare la tua filiale locale di conseguenza. 

Oltre a tirare e spingere, alcuni flussi di lavoro coinvolgere git rebase, come questo, che ho parafrasato dall'articolo collegato:

git pull Origin master
git checkout foo-branch
git rebase master
git Push Origin foo-branch

Se ti trovi in ​​una situazione del genere, potresti essere tentato di git pull --rebase. A meno che tu non sia davvero, davvero so cosa stai facendo, ti consiglierei di non farlo. Questo avviso proviene dalla pagina man per git-pull, versione 2.3.5:

Questa è una modalità di funzionamento potenzialmente pericolosa. Riscrive storia, che non promette nulla di buono quando hai pubblicato quella storia già. Non usare questa opzione se non hai letto git-rebase (1) accuratamente.

145
jfmercer

OK, ecco alcune informazioni su git pull e git fetch, quindi puoi capire le differenze effettive ... in poche semplici parole, fetch ottiene gli ultimi dati, ma non le modifiche al codice e non andando pasticciare con il tuo attuale codice locale, ma pull ottenere le modifiche al codice e unirlo alla tua filiale locale, continua a leggere per ottenere maggiori dettagli su ciascuna:

git fetch

Scaricherà tutti i ref e objects e tutti i nuovi rami nel tuo repository locale ...

Recupera rami e/o tag (collettivamente, "ref") da uno o più altri repository, insieme agli oggetti necessari per completare il loro storie. I rami di monitoraggio remoto vengono aggiornati (vedere la descrizione Di seguito per i modi per controllare questo comportamento).

Per impostazione predefinita, qualsiasi tag che punta nelle cronologie che vengono recuperate è anche preso; l'effetto è di recuperare i tag che puntano ai rami che a cui sei interessato. Questo comportamento predefinito può essere modificato usando le opzioni --tags o --no-tags o configurando remote..tagOpt. Utilizzando un refspec che recupera i tag in modo esplicito, puoi recuperare tag che non puntano ai rami che ti interessano pure.

git fetch può prelevare da un singolo repository o URL, o da diversi repository contemporaneamente se è dato e c'è un telecomandi. entrata nel file di configurazione. (Vedi git-config 1 ).

Quando non viene specificato alcun telecomando, per impostazione predefinita il telecomando Origin sarà usato, a meno che non ci sia un ramo upstream configurato per il corrente ramo.

I nomi dei riferimenti recuperati, insieme ai nomi degli oggetti puntano a, sono scritti su .git/FETCH_HEAD. Questa informazione potrebbe essere usato da script o altri comandi git, come git-pull.


tira fuori

Applicherà le modifiche da remote al ramo corrente in locale ...

Incorpora le modifiche da un repository remoto nel ramo corrente . Nella sua modalità predefinita, git pull è una scorciatoia per git fetch seguito da git si unisce FETCH_HEAD.

Più precisamente, git pull esegue git fetch con i parametri forniti e chiama git merge per unire le branch branch recuperate nell'attuale ramo. Con --rebase, esegue git rebase invece di git merge.

dovrebbe essere il nome di un repository remoto passato a git-fetch 1 . può nominare un ref remoto arbitrario (ad esempio, il nome di un tag) o anche una raccolta di ref con corrispondente rami remoti (ad esempio, ref/heads/: refs/remotes/Origin /), ma di solito è il nome di un ramo nel repository remoto.

I valori predefiniti per e vengono letti dal configurazione "remota" e "unisci" per il ramo corrente come impostato da git-branch --track.


Creo anche il visual qui sotto per mostrarti come git fetch e git pull lavorano insieme ...

 git pull and git fetch

126
Alireza

enter image description here

Questa rappresentazione grafica interattiva è molto utile per comprendere git: http://ndpsoftware.com/git-cheatsheet.html

git fetch semplicemente "scarica" ​​le modifiche dal remoto al tuo repository locale. git pull scarica le modifiche e le unisce al ramo attuale. "Nella sua modalità predefinita, git pull è una scorciatoia per git fetch seguito da git merge FETCH_HEAD."

121
th3sly

Bonus:

Parlando di pull & fetch nelle risposte di cui sopra, mi piacerebbe condividere un trucco interessante,

git pull --rebase

Questo comando sopra è il comando più utile nella mia vita git che ha salvato un sacco di tempo.

Prima di inviare il nuovo commit al server, prova questo comando e sincronizzerà automaticamente le ultime modifiche del server (con un recupero + unione) e posizionerà il commit nella parte superiore del registro git. Non c'è bisogno di preoccuparsi di pull/fusione manuale.

Trova i dettagli su: http://gitolite.com/git-pull--rebase

119

Mi piace avere una rappresentazione visiva della situazione per cogliere queste cose. Forse anche altri sviluppatori vorrebbero vederlo, quindi ecco la mia aggiunta. Non sono completamente sicuro che sia tutto corretto, quindi per favore commenta se trovi errori.

                                         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.

Alcuni dei principali vantaggi di avere un mirror recuperato del telecomando sono:

  • Prestazioni (consente di scorrere tutti i messaggi e i messaggi senza tentare di comprimerlo attraverso la rete)
  • Feedback sullo stato del tuo repository locale (ad esempio, utilizzo SourceTree di Atlassian, che mi darà un bulbo che indica se sono impegnato in anticipo o in ritardo rispetto all'origine.Questa informazione può essere aggiornata con un GIT FETCH ).
109
Justus Romijn

Ho lottato anche con questo. In effetti sono arrivato qui con una ricerca su google della stessa identica domanda. Leggendo tutte queste risposte alla fine ho dipinto un quadro nella mia testa e ho deciso di provare a capirlo guardando lo stato dei 2 repository e 1 sandbox e le azioni eseguite nel tempo mentre guardavo la loro versione. Quindi ecco cosa mi è venuto in mente. Per favore correggimi se ho incasinato ovunque.

I tre repository con un recupero:

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

I tre depositi con un tiro

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

Questo mi ha aiutato a capire perché un recupero è piuttosto importante.

99
pn1 dude

La differenza tra GIT Fetch e GIT Pull può essere spiegata con il seguente scenario: (Tenendo presente che le immagini parlano più delle parole !, ho fornito una rappresentazione pittorica)} _

Prendiamo un esempio che stai lavorando a un progetto con i membri del tuo team. Quindi il loro sarà un ramo principale del progetto e tutti i contributori dovranno trasferirlo al proprio repository locale e quindi lavorare su questo ramo locale per modificare/aggiungere moduli, quindi tornare al ramo principale.

Quindi, Stato iniziale dei due rami quando hai biforcato il progetto principale sul tuo repository locale sarà come questo- (A, B e C sono moduli già completati del progetto)

 enter image description here

Ora hai iniziato a lavorare sul nuovo modulo (supponiamo D) e quando hai completato il modulo D che vuoi spingere sul ramo principale, ma nel frattempo succede che uno dei tuoi compagni di squadra ha sviluppato il nuovo modulo E, F e modificato C.
Quindi ora ciò che è accaduto è che al repository locale manca il progresso originale del progetto e quindi il push delle modifiche al ramo principale può portare a un conflitto e può causare malfunzionamenti del modulo D.

 enter image description here

Per evitare tali problemi e per lavorare in parallelo con il progresso originale del progetto, ci sono due modi:

1. Git Fetch- Questo scaricherà tutte le modifiche apportate al progetto di origine/ramo principale che non sono presenti nella filiale locale. E attenderà il comando Git Merge per applicare le modifiche che sono state recuperate nel tuo repository o ramo.

 enter image description here

Quindi ora puoi monitorare attentamente i file prima di unirli al tuo repository. E puoi anche modificare D se richiesto a causa di C modificato.

 enter image description here

2. Git Pull- Questo aggiornerà il tuo ramo locale con il ramo Origin/main cioè in realtà ciò che fa è la combinazione di Git Fetch e Git si fondono uno dopo l'altro .Ma questo può causare conflitti a si verifica, quindi si consiglia di utilizzare Git Pull con una copia pulita.

 enter image description here

89
Aman Tiwari

Diciamo semplicemente:

git pull == git fetch + git merge

Se esegui git pull, non è necessario unire i dati in locale. Se si esegue git fetch, significa che è necessario eseguire git merge per ottenere l'ultimo codice sul computer locale. In caso contrario, il codice macchina locale non verrà modificato senza unione. 

Quindi in Git Gui, quando si esegue il recupero, è necessario unire i dati. Recupero stesso non apporterà le modifiche al codice sul tuo locale. Puoi verificarlo quando aggiorni il codice recuperando Una volta recuperato e visto; il codice non cambierà. Quindi ti unisci ... Vedrai il codice modificato.

82
Selvamani

git fetch estrae il codice dal server remoto ai rami di tracciamento nel repository locale. Se il tuo remoto è chiamato Origin (il valore predefinito), questi rami si troveranno entro Origin/, ad esempio Origin/master, Origin/mybranch-123, ecc. Questi non sono i tuoi rami correnti, sono copie local di quei rami dal server.

git pull fa un git fetch ma poi anche unisce il codice dal ramo di tracciamento alla versione locale corrente di quel ramo. Se non sei ancora pronto per tali modifiche, solo git fetch prima.

80
Michael Durrant

git fetch recupererà i rami remoti in modo che tu possa git diff o git merge loro con il ramo corrente. git pull eseguirà il recupero sulla traccia remota tracciata dal ramo corrente e quindi unirà il risultato. Puoi usare git fetch per vedere se ci sono aggiornamenti al ramo remoto senza doverli unire con il tuo ramo locale.

75
ntanase

Git Fetch

Puoi scaricare le modifiche al tuo ramo locale da Origin tramite fetch. Fetch chiede al repository remoto tutti i commit che altri hanno fatto ma che non hai sul tuo repository locale. Fetch scarica questi commit e li aggiunge al repository locale.

Git Merge

Puoi applicare le modifiche scaricate tramite fetch usando il comando di fusione. Unisci prenderà i commit recuperati dal recupero e cercherà di aggiungerli al tuo ramo locale. L'unione manterrà la cronologia dei commit delle modifiche locali in modo che quando condividi il tuo ramo con Push, Git saprà in che modo gli altri possono unire le tue modifiche.

Git Pull

Recupero e unione vengono eseguiti insieme abbastanza spesso che è stato creato un comando che combina i due, pull. Pull fa un recupero e poi un'unione per aggiungere i commit scaricati nella tua filiale locale.

71
Pinkesh Sharma

L'unica differenza tra git pull e git fetch è che:

git pull estrae da un ramo remoto e lo unisce.

git fetch recupera solo dal ramo remoto ma non si unisce

cioè git pull = git fetch + git merge ...

50

Git consente di applicare cronologicamente i commit più vecchi dopo i nuovi commit . Per questo motivo, l'atto di trasferire i commit tra repository è diviso in due passaggi:

  1. Copia di nuovi commit dal ramo remoto per copiare questo ramo remoto all'interno del repository locale. 

    (operazione pronti contro termine) [email protected] >> remote/Origin/[email protected]

  2. Integrazione di nuovi commit alla filiale locale

    (operazione inside-repo) remote/Origin/[email protected] >> [email protected]

Esistono due modi per eseguire il passaggio 2. È possibile:

  1. Fork branch locale dopo l'ultimo antenato comune e aggiunta di nuovi commit paralleli a commit che sono univoci per il repository locale, finalizzati dall'unione di commit, chiudendo il fork. 
  2. Inserire nuovi commit dopo l'ultimo antenato comune e riapplicare univoco al repository locale.

Nella terminologia git, il passaggio 1 è git fetch, il passaggio 2 è git merge o git rebase

git pull è git fetch e git merge

44
Pawel Furmaniak

Qual è la differenza tra git pull e git fetch?

Per capire questo, devi prima capire che il tuo git locale mantiene non solo il tuo repository locale, ma mantiene anche una copia locale del repository remoto.

git fetch porta la copia locale dell'archivio remoto aggiornata. Ad esempio, se il tuo repository remoto è GitHub, potresti voler recuperare tutte le modifiche apportate nel repository remoto alla tua copia locale del repository remoto. Ciò ti consentirà di eseguire operazioni come confrontare o unire.

git pull d'altra parte farà cadere le modifiche nel repository remoto al punto in cui manterrai il tuo codice. In genere, git pull eseguirà un git fetch prima di aggiornare la copia locale dell'archivio remoto e quindi unirà le modifiche nel proprio repository di codice e possibilmente nella propria copia di lavoro. 

36
Donal

Git ottiene il ramo dell'ultima versione dal remoto al locale usando due comandi: 

  1. git fetch: Git sta per ottenere l'ultima versione da remota a locale, ma non si unisce automaticamente git fetch Origin mastergit log -p master..Origin/mastergit merge Origin/master

     I comandi sopra indicano che scaricare l'ultima versione del ramo principale da Origine dal ramo principale remoto a Origine. Quindi confronta il ramo master locale e il ramo principale di origine. Infine, unisci. 

  2. git pull: Git sta per ottenere l'ultima versione dal telecomando e unirsi al locale.

     git pull Origin master

     Il comando sopra è equivalente a git fetch e git merge. In pratica, git fetch potrebbe essere più sicuro perché prima della fusione possiamo vedere le modifiche e decidere se unire.

35
Marcus Thornton

git pull == (git fetch + git merge) 

git fetch non cambia alle filiali locali.

Se si dispone già di un repository locale con una configurazione remota per il progetto desiderato, è possibile afferrare tutti i rami e i tag per il telecomando esistente utilizzando git fetch. ... Fetch non apporta modifiche ai rami locali, quindi sarà necessario unire un ramo remoto con un ramo locale abbinato per incorporare le nuove modifiche di recupero. da github

33
Iggy

In realtà Git mantiene una copia del proprio codice e Il repository remoto.

Il comando git fetch rende aggiornata la tua copia locale recuperando i dati dal repository remoto. Il motivo per cui abbiamo bisogno di questo è perché qualcun altro potrebbe aver apportato alcune modifiche al codice e vuoi tenerti aggiornato. 

Il comando git pull porta le modifiche nel repository remoto a dove mantieni il tuo codice. Normalmente, git pull esegue questa operazione facendo prima un 'git fetch' per aggiornare la copia locale del repository remoto, quindi unisce le modifiche nel proprio repository di codice e possibilmente nella propria copia di lavoro.

32
Pokemon

Cercando di essere chiari e semplici.

Il comando git pull è in realtà un shortcut per git fetch seguito da git merge o git rebase command a seconda della configurazione. Puoi configurare il tuo repository Git in modo che git pull sia un fetch seguito da un rebase.

31
montells

Una semplice rappresentazione grafica per principianti,

 enter image description here

qui,

git pull  

recupererà il codice dal repository e rebase con il tuo locale ... in Git Pull c'è la possibilità che vengano creati nuovi commit.

ma in , 

git fetch 

recupererà il codice dal repository e dovremo rebase manualmente usando git rebase

ad esempio: sto andando a recuperare dal server master e rebase nel mio master locale.

1) git pull (rebase verrà eseguito automaticamente):

git pull Origin master

qui Origin è il tuo repo remoto master è il tuo ramo

2) git fetch (necessario rebase manualmente):

git fetch Origin master

recupererà le modifiche del server da Origin. e sarà nel tuo locale fino a quando non lo ridicherai da solo. abbiamo bisogno di risolvere i conflitti manualmente controllando i codici.

git rebase Origin/master

questo rebase il codice in locale. prima assicurati di essere nel ramo giusto.

30
git pull = git fetch + git merge 
29
Saqib R.

Da Pro Git § 2.5 Nozioni di base su Git - Lavorare con i Remoti: Recupero e estrazione dai tuoi telecomandi :

È importante notare che il comando fetch richiama i dati nel tuo repository locale - non lo fa lo unisci automaticamente con qualsiasi tuo lavoro o modifica ciò che sei attualmente lavorando. Devi unirlo manualmente al tuo lavoro quando sei pronto.

Se hai un ramo configurato per tracciare un ramo remoto, puoi usare il git pull comando per recuperare automaticamente e quindi unire un remoto diramazione nel tuo ramo attuale. Questo potrebbe essere più facile o più flusso di lavoro confortevole per te; e per impostazione predefinita, il comando git clone imposta automaticamente il ramo master locale per tracciare il telecomando ramo principale sul server da cui è stato clonato (supponendo che il telecomando abbia un ramo master ). L'esecuzione di git pull generalmente recupera i dati dal server originariamente clonato e tenta automaticamente di unirlo nel codice su cui stai attualmente lavorando.

28
Zhenxiao Hao

git pull 

Esegue due funzioni utilizzando un singolo comando.

Raccoglie tutte le modifiche apportate al ramo remoto e quindi le unisce nel ramo locale. Puoi anche modificare il comportamento di pull passando --rebase. La differenza tra fusione e rebase può essere letta qui

git fetch

Git fetch fa solo la metà del lavoro di Git Pull. Porta solo le modifiche remote nel repository locale ma non le applica ai rami. Devi applicare esplicitamente tali modifiche. Questo può essere fatto come segue:

git fetch
git rebase Origin/master
22
Animesh Sharma

Bisogna tenere a mente la natura del git. Hai telecomandi e le tue filiali locali (non necessariamente le stesse). In confronto ad altri sistemi di controllo sorgente questo può essere un po 'perplesso. 

Di solito quando esegui il checkout su un telecomando viene creata una copia locale che tiene traccia del telecomando. 

git fetch funzionerà con il ramo remoto e aggiornerà le tue informazioni. 

In realtà, se altri SWE stanno lavorando su uno stesso ramo, e raramente nel caso di un piccolo sviluppo - un ramo - uno scenario di progetto.

Il tuo lavoro sulla filiale locale è ancora intatto. Per portare le modifiche al tuo ramo locale devi unire/rebase le modifiche dal ramo remoto.

git pull fa esattamente questi due passi (vale a dire --rebase to rebase invece di unire)

Se la cronologia locale e la cronologia remota sono in conflitto, sarai costretto a fare l'unione durante un git Push per pubblicare le tue modifiche.

Quindi dipende molto dalla natura del tuo ambiente di lavoro e sperimenta cosa usare.

22
g24l

Da git cheat sheet

git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD
20
Nan Xiao

Da quello che ho capito, 

Git pull - Tira verso il basso da un telecomando specificato (specificato dall'utente) e lo unirà immediatamente in un ramo in cui ci troviamo attualmente. È fondamentalmente un mix di comandi Fetch e Unisci.

Git Fetch - È uguale a Pull, ma non esegue alcuna fusione. Quindi puoi monitorare attentamente i file prima di unirli. 

Questo url deve essere di aiuto per un'ulteriore comprensione: La differenza tra git pull, git fetch e git clone (e git rebase).

17
Pragyaditya Das

In termini brevi e semplici:

git fetch: guarda se ci sono novità.

git pull: prendi le nuove cose e mettile sopra le tue cose. 

8
miva2

Credo che la maggior parte delle risposte abbia risposto alla differenza abbastanza bene. Vorrei sottolineare su quando usare quale invece.

 Enter image description here

Il recupero può essere utile quando devi ottenere l'aggiornamento di altri sviluppatori, ma vuoi continuare il tuo lavoro senza ostacoli. Le persone che spesso vogliono andare offline e lavorano utilizzano fetch per ottenere l'ultimo aggiornamento fino a quando non è online. Più tardi quando lui/lui è a suo agio con i suoi cambiamenti, unisce quelli del ramo nel suo spazio di lavoro.

Mentre le persone che lavorano online e sono molto sicure delle loro modifiche e vogliono ottenere l'ultimo codice e merge utilizza immediatamente pull. Uso raramente fetch perché per verificare gli ultimi aggiornamenti li controllo tramite il sito Web GitHub e lavoro sempre offline. Come ho detto, potresti averlo usato per lo scenario sopra.

5
ishandutta2007

Git Fetch

Ti aiuta a farti conoscere gli ultimi aggiornamenti da un git repository. Diciamo che lavori in un team usando GitFlow, dove il team lavora su più branches (caratteristiche). Con git fetch --allcommand è possibile ottenere informazioni su tutti i nuovi branches all'interno di repository.

Per lo più git fetch è usato con git reset. Ad esempio, si desidera ripristinare tutte le modifiche locali allo stato attuale del repository.

git fetch --all // get known about latest updates
git reset --hard Origin/[branch] // revert to current branch state

Git pull

Questo comando aggiorna branch con lo repositorybranch corrente. Continuiamo con GitFlow. Caratteristica multipla branches era merged a develop branch e quando vuoi sviluppare nuove funzionalità per il progetto devi andare a sviluppare branch e fare un git pull per ottenere lo stato corrente di developbranch

Documentazione per GitFlow https://Gist.github.com/peterdeweese/4251497

3
Andrei Todorut

Git fetch sincronizza il catalogo del repository remoto sul tuo locale. Non unirà le modifiche al file/codice dal remoto al ramo locale.

Git pull scarica le modifiche relative al tuo ramo locale corrente e quindi lo unifica.

1
Arnel Lenteria

Da questo fantastico attoriale tutorial: 

Il comando git fetch scarica commit, file e ref da un repository remoto nel repository locale. 

Il recupero è ciò che fai quando vuoi vedere a cosa stanno lavorando tutti else. È simile all'aggiornamento di svn in quanto consente di vedere come è progredita la cronologia centrale, ma non obbliga a unire le modifiche nel repository. Git isola il contenuto recuperato come contenuto dal contenuto locale esistente, ha assolutamente nessun effetto sul lavoro di sviluppo locale. Il contenuto recuperato deve essere esplicitamente estratto utilizzando il comando git checkout. Questo rende il recupero un modo sicuro per rivedere le commit prima di integrarle con il tuo repository locale.

Quando si scaricano contenuti da un repository remoto, sono disponibili i comandi git pull e git fetch per eseguire l'operazione. Puoi considerare git fetch la versione "sicura" dei due comandi. Scaricherà il contenuto remoto ma non aggiornerà lo stato di lavoro del repository locale, lasciando intatto il lavoro corrente. git pull è l'alternativa più aggressiva, scaricherà il contenuto remoto per il ramo locale attivo e eseguirà immediatamente git merge per creare un commit di unione per il nuovo contenuto remoto. Se sono in corso modifiche in corso, ciò causerà conflitti e kickoff del flusso di risoluzione dei conflitti di fusione.


Con git pull:

  • Non si ottiene alcun isolamento. 
  • Colpisce sul tuo sviluppo locale.
  • Non ha bisogno di essere esplicitamente controllato. Perché implicitamente fa un git merge.
  • Fondamentalmente NON è sicuro. È aggressivo.
  • A differenza di git fetch in cui ha effetto solo su .git/refs/remotes, git pull avrà effetto sia su .git/refs/remotesche su.git/refs/heads/.

Hmmm ... quindi se non sto aggiornando la copia di lavoro con git fetch, allora dove sto apportando modifiche? Dove git fetch memorizza i nuovi commit?

Grande domanda. Lo mette da qualche parte isolato dalla tua copia di lavoro. Ma di nuovo dove? Scopriamolo.

Nella directory del tuo progetto (cioè dove esegui i tuoi comandi git): 

  1. ls. Questo mostrerà i file e le directory. Niente di fico, lo so.

  2. Ora fai ls -a. Questo mostrerà dot file ie file che iniziano con . Sarai quindi in grado di vedere una directory chiamata: .git

  3. Fai cd .git. Questo ovviamente cambierà la tua directory. 
  4. Ora arriva la parte divertente; fai ls. Verrà visualizzato un elenco di directory. Stiamo cercando refs. Fai cd refs.
  5. È interessante vedere cosa c'è dentro tutte le directory, ma concentriamoci su due di esse. heads e remotes. Usa cd per controllare anche dentro di loro. 
  6. QUALUNQUE git fetch che fai aggiornerà gli elementi nella directory /.git/refs/remotes. Non aggiornerà nulla nella directory /.git/refs/heads.
  7. ANY git pull eseguirà prima git fetch, aggiornerà gli elementi nella directory /.git/refs/remotes, quindi si unirà al tuo locale e quindi cambierà la testa all'interno della directory /.git/refs/heads

Si può trovare anche una buona risposta correlata Dove si posiziona 'git fetch'?

Cerca anche "Notazione barra" da Convenzioni di denominazione dei rami Git post.

1
Honey