Introduzione

git pull è zucchero per git fetch seguito dall'integrazione del branch upstream nel branch corrente. Il passo di integrazione è un merge (default) o un rebase.

I due passi

1. git fetch <remote> <refspec>: scarica e aggiorna i ref di tracking.
2. Se pull.rebase è false: git merge FETCH_HEAD.
3. Se pull.rebase è true: git rebase FETCH_HEAD.

Sequenza manuale equivalente:

git fetch origin main
git merge origin/main             # o git rebase origin/main

Configurazione

git config --global pull.rebase false   # merge (default classico)
git config --global pull.rebase true    # rebase
git config --global pull.ff only        # solo fast-forward, altrimenti aborta

Da Git 2.27, git pull nudo senza configurazione stampa un avviso. Scegli una strategia esplicitamente.

Solo fast-forward

--ff-only è il pull più sicuro: riesce solo se il tuo branch è strettamente indietro. Nessun merge commit, nessun rebase, nessuna sorpresa.

git pull --ff-only

Combina con autostash per evitare blocchi della working tree:

git pull --ff-only --autostash

Pull con rebase

git pull --rebase
git pull --rebase=merges          # preserva la struttura merge

--rebase=merges è utile per branch che contengono merge commit che vuoi mantenere.

Pull con autostash

git config --global rebase.autoStash true
git config --global merge.autoStash true

Con questi attivi, le tree sporche vengono fatte stash prima dell'integrazione e riapplicate dopo, in modo trasparente.

Pull multi-branch

git pull origin main feature        # scarica entrambi, mergia octopus in HEAD

Questo è raramente ciò che vuoi; preferisci operazioni separate.

Pull vs fetch + integra esplicito

Molti utenti esperti preferiscono non usare mai git pull. Eseguono prima git fetch, ispezionano git log HEAD..@{u}, e poi scelgono merge o rebase deliberatamente. Questo è particolarmente prezioso quando si integrano branch divergenti di lunga vita.

Politiche di pull per i team

I team sani scelgono una singola politica di pull e la configurano a livello di organizzazione. Due scelte comuni:

# Team con storia lineare: rebase su pull, merge solo via PR
git config --global pull.rebase true
git config --global rebase.autoStash true

# Team merge-friendly: mai rebase, sempre fast-forward main
git config --global pull.rebase false
git config --global pull.ff only

La configurazione peggiore è quella assente: il git pull di ogni sviluppatore si comporta diversamente, producendo storie inconsistenti. Documenta la politica nel CONTRIBUTING.md del tuo repo e fornisci uno snippet di config di una riga che i nuovi contributori possono copiare.

Errori comuni

Eseguire git pull con modifiche non committate e ottenere un merge commit inaspettato sopra del lavoro sporco. O fai stash, committa, o imposta autoStash. Fare pull con rebase su un branch su cui altri hanno basato lavoro; riscrivi la loro base. Rebase solo su branch privati. Configurare pull.rebase globalmente senza rendersi conto che influenza anche main; molti team impostano pull.ff only globalmente e fanno override per branch. Infine, usare git pull in CI; la CI raramente ha bisogno di integrazione, solo dell'ultimo commit. Usa git fetch e un checkout esplicito di origin/main per mantenere la CI deterministica.