git pull

Il comando git pull è usato per recuperare e scaricare il contenuto da un repository remoto e aggiornare immediatamente il repository locale per farlo corrispondere a quel contenuto. Unire le modifiche remote a monte nel tuo repository locale è un compito comune nei flussi di lavoro di collaborazione basati su Git. Il comando git pull è in realtà una combinazione di altri due comandi, git fetch seguito da git merge. Nella prima fase dell’operazione git pull eseguirà un git fetch scopiazzato al ramo locale che HEAD è puntato. Una volta che il contenuto è stato scaricato, git pull entrerà in un flusso di lavoro di fusione. Un nuovo merge commit verrà creato e HEAD aggiornato per puntare al nuovo commit.

Uso di Git pull

Il comando git pull esegue prima git fetch che scarica il contenuto dal repository remoto specificato. Poi viene eseguito un git merge per unire i contenuti remoti e le teste in un nuovo commit locale. Per dimostrare meglio il processo di pull e merge consideriamo il seguente esempio. Supponiamo di avere un repository con un ramo master e un’origine remota.

In questo scenario, git pull scaricherà tutte le modifiche dal punto in cui il locale e il master divergono. In questo esempio, quel punto è E. git pull recupererà i commit remoti divergenti che sono A-B-C. Il processo di pull creerà quindi un nuovo merge commit locale contenente il contenuto dei nuovi commit remoti divergenti.

Nel diagramma sopra, possiamo vedere il nuovo commit H. Questo commit è un nuovo merge commit che contiene il contenuto dei commit remoti A-B-C e ha un messaggio di log combinato. Questo esempio è una delle poche git pull strategie di fusione. Un’opzione --rebase può essere passata a git pull per usare una strategia di fusione rebase invece di un commit di fusione. Il prossimo esempio dimostrerà come funziona un rebase pull. Supponiamo di essere al punto di partenza del nostro primo diagramma, e di aver eseguito git pull --rebase.

In questo diagramma, possiamo ora vedere che un rebase pull non crea il nuovo commit H. Invece, il rebase ha copiato i commit remoti A–B–C e riscritto i commit locali E–F–G per apparire dopo di loro nella cronologia dei commit locali origin/master.

Opzioni comuni

git pull <remote>

Preleva la copia remota specificata del ramo corrente e la unisce immediatamente alla copia locale. Questo è lo stesso di git fetch <remote> seguito da git merge origin/<current-branch>.

git pull --no-commit <remote>

Simile all’invocazione di default, recupera il contenuto remoto ma non crea un nuovo merge commit.

git pull --rebase <remote>

Come il pull precedente Invece di usare git merge per integrare il ramo remoto con quello locale, usa git rebase.

git pull --verbose

Dà un output verboso durante un pull che mostra il contenuto scaricato e i dettagli della fusione.

Discussione sul pull di Git

Si può pensare a git pull come alla versione di Git di svn update. È un modo semplice per sincronizzare il tuo repository locale con i cambiamenti a monte. Il seguente diagramma spiega ogni passo del processo di pulling.

Si inizia pensando che il proprio repository sia sincronizzato, ma poi git fetch rivela che la versione di master di origin è progredita dall’ultimo controllo. Quindi git merge integra immediatamente il master remoto in quello locale.

Git pull e sincronizzazione

git pull è uno dei molti comandi che rivendicano la responsabilità di ‘sincronizzare’ il contenuto remoto. Il comando git remote è usato per specificare su quali endpoint remoti opereranno i comandi di sincronizzazione. Il comando git push è usato per caricare contenuti in un repository remoto.

Il comando git fetch può essere confuso con git pull. Sono entrambi usati per scaricare contenuti remoti. Un’importante distinzione di sicurezza può essere fatta tra git pull e get fetchgit fetch può essere considerato l’opzione “sicura” mentre, git pull può essere considerato non sicuro. git fetch scaricherà il contenuto remoto e non altererà lo stato del repository locale. In alternativa, git pull scaricherà il contenuto remoto e tenterà immediatamente di cambiare lo stato locale per farlo corrispondere a quel contenuto. Questo potrebbe involontariamente causare uno stato conflittuale del repository locale.

Pulling via Rebase

L’opzione --rebase può essere usata per assicurare una storia lineare evitando inutili commit di merge. Molti sviluppatori preferiscono il rebasing al merge, poiché è come dire: “Voglio mettere le mie modifiche in cima a ciò che tutti gli altri hanno fatto”. In questo senso, usare git pull con il flag --rebase è ancora più simile a svn update di un semplice git pull.

In effetti, tirare con --rebase è un flusso di lavoro così comune che esiste un’opzione di configurazione dedicata per questo:

git config --global branch.autosetuprebase always

Dopo aver eseguito questo comando, tutti i comandi git pull si integreranno tramite git rebase invece di git merge.

Esempi di Git Pull

I seguenti esempi dimostrano come usare git pull in scenari comuni:

Comportamento predefinito

git pull

Eseguire l’invocazione predefinita di git pull sarà equivalente a git fetch origin HEAD e git merge HEAD dove HEAD è il ref che punta al ramo corrente.

Git pull sui remoti

git checkout new_feature
git pull <remote repo>

Questo esempio esegue prima un checkout e passa al ramo. In seguito, il git pull viene eseguito con il passaggio. Questo tirerà giù implicitamente il ramo newfeature da . Una volta che il download è completo, verrà avviato un git merge.

Git pull rebase invece di merge

L’esempio seguente dimostra come sincronizzarsi con il ramo master del repository centrale usando un rebase:

git checkout master
git pull --rebase origin

Questo semplicemente sposta le tue modifiche locali in cima a ciò che tutti gli altri hanno già contribuito.