git fetch vs git pull: scaricare con consapevolezza

git fetch scarica informazioni dal remoto e aggiorna i remote-tracking branch. Non modifica il tuo branch locale e non tocca il working tree.

git pull invece fa fetch e poi integra subito: con merge o rebase, a seconda della configurazione.

Perché questa lezione conta

git pull è comodo, ma spesso troppo implicito. Se non sai cosa sta arrivando dal remoto, puoi generare merge commit inattesi, conflitti nel momento sbagliato o rebase non voluti.

Il flusso fetch-prima ti permette di osservare prima di integrare.

Obiettivo operativo

Alla fine della lezione devi saper usare fetch per aggiornare la vista remota, confrontare locale e remoto, e scegliere consapevolmente merge, rebase o fast-forward.

Fetch

git fetch origin

Aggiorna riferimenti come origin/main. Non cambia main.

Per tutti i remote:

git fetch --all --prune

--prune rimuove riferimenti remoti a branch cancellati sul server.

Cosa è cambiato sul remoto

Dopo fetch:

git log HEAD..origin/main --oneline

Mostra commit che sono su origin/main ma non sul tuo branch corrente.

git log origin/main..HEAD --oneline

Mostra commit locali non presenti su origin/main.

Per un confronto grafico:

git log --graph --oneline --decorate --all

Pull

git pull equivale a:

git fetch
git merge

oppure, se configurato:

git fetch
git rebase

Controlla:

git config --get pull.rebase

Se il team non ha una regola, ogni sviluppatore può integrare in modo diverso.

Pull sicuro

Se vuoi solo fast-forward:

git pull --ff-only

Se il tuo branch ha commit locali divergenti, il comando fallisce invece di creare un merge automatico.

Per branch personali:

git pull --rebase

Può mantenere storia lineare, ma riscrive commit locali.

Configurazione esplicita

Git moderno può chiederti di scegliere una strategia quando i branch divergono. Meglio decidere prima, a livello di team:

git config --global pull.ff only

oppure:

git config --global pull.rebase true

pull.ff only è severo: aggiorna solo se il tuo branch può avanzare senza creare merge commit. pull.rebase true è comodo sui branch personali, ma non va imposto se il team mantiene merge commit intenzionali.

La regola deve essere scritta. Se resta implicita, due sviluppatori possono ottenere storie diverse partendo dagli stessi commit.

Routine consigliata

git status -sb
git fetch origin
git log --oneline --decorate HEAD..origin/main
git log --oneline --decorate origin/main..HEAD

Poi decidi:

git merge --ff-only origin/main

oppure:

git rebase origin/main

La scelta dipende dal workflow.

Laboratorio guidato

Simula con due cloni dello stesso repo:

1. nel clone A fai commit e push;
2. nel clone B esegui solo fetch;
3. verifica che i file locali non cambiano;
4. guarda origin/main;
5. integra con merge fast-forward;
6. ripeti creando divergenza locale e osserva cosa fa pull.

Output atteso

Una regola personale:

Fetch prima di pull quando non so cosa è cambiato.
Pull --ff-only su main.
Pull --rebase solo su branch personali se previsto.

Errori comuni

Usare pull come riflesso. Può integrare senza che tu abbia visto cosa arriva.

Non conoscere pull.rebase. Il comportamento cambia da macchina a macchina.

Confondere fetch con aggiornamento dei file. Fetch aggiorna riferimenti remoti, non il working tree.

Dimenticare prune. Branch remoti cancellati restano visibili e creano rumore.

Checklist di verifica

• so cosa modifica git fetch;
• so cosa fa git pull;
• so confrontare HEAD..origin/main;
• so usare --ff-only;
• il team ha deciso merge o rebase per pull.

Collegamenti

• Modulo: Collaborazione con remoti — lezione 22 del corso.
• Push e upstream sono il passo successivo.