Git Fetch vs Pull: capire le differenze

Sincronizzare i repository locali con i rispettivi remoti è un aspetto fondamentale del lavoro con Git.

Due comandi spesso confusi quando si accede al codice in remoto sono git fetch e git pull. Anche se sembrano simili, le loro differenze hanno implicazioni significative per il code review, la gestione dei branch e la produttività complessiva del team.

In questo articolo vedremo cosa fa ciascuna funzione, alcuni esempi e anche alcune best practice per usarle. Se stai ancora imparando Git, ti consiglio di dare un'occhiata al nostro percorso di competenze Git Fundamentals. 

Differenze chiave tra Git Fetch e Git Pull

Pur essendo correlati, i comandi differiscono sia nel comportamento sia nell'intento.

Confrontiamoli nella tabella qui sotto:

Come vedi, i comandi differiscono sia nel comportamento sia nell'intento:

• git fetch aggiorna solo i riferimenti di tracciamento remoto, lasciando intatto il tuo branch di lavoro.
• git pull aggiorna i riferimenti di tracciamento remoto e li integra subito nel branch corrente.

Guida visiva: come funzionano Git Fetch e Pull

Come mostrato nel flusso visivo sopra, le differenze tra fetch e pull riguardano dove fluisce il tuo codice.

In sintesi:

• Fetch: i commit remoti confluiscono nei branch di tracciamento remoto (origin/main). Il tuo main locale resta invariato, dandoti visibilità sugli aggiornamenti senza interruzioni.
• Pull: i commit remoti confluiscono nei branch di tracciamento remoto e poi vengono uniti o rimbasati nel tuo branch locale, spostando subito il puntatore del branch.

Panoramica dell'architettura di un repository Git

Per apprezzare appieno git fetch e git pull, dobbiamo comprendere la struttura interna di Git e i livelli in gioco.

Git è fondamentalmente un sistema di controllo versione distribuito, il che significa che ogni sviluppatore ha una copia completa del repository, inclusi cronologia, branch e tag.

Questa architettura consente di lavorare in modo indipendente da un server centrale, rendendo comandi come fetch e pull i ponti che mantengono sincronizzati gli ambienti distribuiti.

I repository Git operano su più livelli:

• Working directory: i file effettivi che vedi e modifichi. Qui scrivi codice, modifichi testi ed esegui build. Le modifiche qui non sono tracciate finché non le metti esplicitamente in stage.
• Staging area (Index): una zona cuscinetto dove prepari un insieme curato di modifiche da fare commit. Consente un controllo fine su ciò che entra nella storia del progetto.
• Repository locale: la directory .git che contiene il database di tutti i commit, i branch, i tag e la configurazione. È interamente locale e non cambia a meno che tu non faccia commit o sincronizzi esplicitamente.
• Repository remoto: ospitato altrove (ad esempio GitHub, GitLab, Bitbucket), funge da hub di collaborazione per più sviluppatori. È il terreno comune dove i team condividono i progressi.

Questi livelli funzionano in modo indipendente, il che significa che la sincronizzazione con un remoto non influisce immediatamente sulla tua working directory.

Le modifiche si propagano invece gradualmente in quest'ordine:

remote → branch di tracciamento remoto → repository locale → working directory.

Branch di tracciamento remoto

I branch di tracciamento remoto sono riferimenti speciali che rappresentano lo stato dei branch nel repository remoto.

Per esempio, origin/main indica dove si trovava il branch main sul remoto origin l'ultima volta che hai eseguito fetch.

Funzionano come segnalibri, permettendoti di:

• Confrontare il tuo branch con la versione remota.
• Vedere quali commit sono in attesa di integrazione.
• Tracciare in sicurezza l'avanzamento remoto senza cambiare il tuo codice attuale.
• Quando esegui git fetch, Git aggiorna questi branch di tracciamento remoto.
• Quando fai merge o rebase, sposti le modifiche da quei riferimenti di tracciamento remoto nel tuo branch locale.

Questa separazione significa che puoi osservare e analizzare gli aggiornamenti prima che influenzino il tuo lavoro di sviluppo reale. Puoi saperne di più nel nostro tutorial su Git remote. 

Che cos'è Git Fetch?

git fetch recupera commit, branch e tag da un repository remoto e aggiorna i tuoi branch di tracciamento remoto senza alterare il branch corrente o i file di lavoro.

Pensalo come "scaricare la mappa più aggiornata del repository remoto" senza entrare nel nuovo territorio.

È particolarmente utile per chi vuole visibilità sull'attività remota senza rischiare modifiche indesiderate al proprio lavoro.

Sintassi e utilizzo

Il comando si usa nel terminale bash o nell'interfaccia a riga di comando (CLI). Ecco alcuni dettagli di sintassi a cui fare attenzione:

Comandi fetch comuni:

# Fetch all remotes
git fetch --all

# Fetch only one branch
git fetch origin main

# Fetch and prune stale references
git fetch --prune

# Fetch a specific tag
git fetch origin tag v1.2.0

Ecco la spiegazione di ciascun comando e delle rispettive opzioni:

• --all fa sì che vengano aggiornati tutti i remoti configurati, utile in setup con più remoti.
• Recuperare un singolo branch con git fetch origin main è efficiente se ti interessa solo un flusso di lavoro.
• --prune rimuove i branch di tracciamento remoto obsoleti che non esistono più sul server, mantenendo pulito l'ambiente.
• Recuperare tag con git fetch origin tag è utile nei workflow di rilascio in cui i commit taggati contano più dei branch completi.

Casi d'uso comuni

Gli sviluppatori usano git fetch in vari scenari in cui contano visibilità e controllo. Per esempio:

• Code review: usa fetch per vedere cosa hanno pushato gli altri prima di decidere di integrare.
• Pianificazione dell'integrazione: confronta le modifiche in origin/main con il tuo branch locale per preparare merge o rebase.
• Collaborazione: evita merge automatici dirompenti eseguendo fetch, revisione e merge con i tuoi tempi.
• Sperimentazione: spesso si fa fetch degli aggiornamenti in un branch separato per testare nuove funzionalità senza disturbare il branch principale.
• Monitoraggio continuo: i team possono eseguire fetch regolarmente per mantenere mirror locali del repository remoto aggiornati per strumenti di reportistica o analisi.

Che cos'è Git Pull?

git pull è più aggressivo di fetch perché scarica le modifiche e tenta subito di integrarle nel tuo branch corrente.

Questo significa che il comando git pull è una combinazione dei comandi git fetch e git merge.

Per impostazione predefinita, l'integrazione è un merge, ma può essere configurata per usare il rebase. Comodo, questo comando presuppone che tu voglia applicare subito gli aggiornamenti remoti.

È il comando di riferimento per chi privilegia velocità e sincronizzazione immediata.

Sintassi e utilizzo

Vediamo ora la sintassi di utilizzo di questo comando.

Ecco alcuni esempi:

# Default fetch + merge
git pull origin main

# Fetch + rebase for cleaner history
git pull --rebase origin main

# Pull all changes from default remote
git pull

# Pull with fast-forward only (avoids merge commits)
git pull --ff-only

Ecco la spiegazione del codice sopra:

• Con il merge, potresti ottenere commit di merge aggiuntivi, espliciti ma a volte rumorosi.
• Con --rebase, Git riapplica i tuoi commit locali sopra il branch remoto, creando una storia più pulita e lineare.
• Usare l'opzione --ff-only garantisce l'avanzamento fast-forward del branch senza merge non necessari, spesso desiderabile per workflow puliti.

In Git, "fast-forward" si riferisce a un tipo specifico di operazione di merge che si verifica quando il branch in cui stai facendo il merge non è divergente rispetto al branch da cui stai facendo il merge. 

Questo significa che non ci sono nuovi commit sul branch di destinazione (quello su cui ti trovi) che non siano presenti anche nel branch di origine (quello che stai unendo).

In sostanza, il fast-forward è un processo di merge semplificato che rende più lineare la cronologia quando si mantiene una progressione lineare dei commit tra i branch.

Casi d'uso comuni

Questo comando può essere usato in vari casi per controllare il codice in sviluppo, ad esempio:

• Ambienti Agile: integrazioni frequenti garantiscono che tutti lavorino sull'ultimo codice.
• Pipeline di continuous delivery: automatizzare i pull assicura che i server di deploy siano sempre aggiornati.
• Workflow affidabili: quando gli aggiornamenti remoti sono garantiti stabili e le revisioni del codice sono già completate.
• Progetti individuali: pull è più veloce quando sei l'unico contributor e non devi revisionare il codice altrui.

Considerazioni su sicurezza e controllo

Il comando git pull può comportare alcune criticità. Ecco alcuni aspetti di sicurezza da considerare:

• Pull offre comodità: tutto avviene in un solo passaggio, ma rinunci a parte del controllo.
• Gestione degli errori: pull può introdurre conflitti subito, mentre fetch ti consente di prepararti in anticipo.
• Chiarezza della storia: i workflow fetch-first mantengono la storia più pulita e facile da auditare, mentre pull può riempire la storia di rumore se usato con poca attenzione.
• Impatto sulla collaborazione: fare pull troppo in fretta può far introdurre inconsapevolmente modifiche instabili nei branch condivisi.

Quando usare Git Fetch vs Git Pull

La scelta tra fetch e pull dipende dal workflow e dai requisiti del progetto.

• Usa fetch quando:
• Vuoi fare una revisione prima di integrare.
• Lavori su progetti ad alto impatto in cui la stabilità conta.
• Il tuo team valorizza merge deliberati dopo il code review.
• Vuoi mantenere una storia pulita senza merge aggiuntivi.
• Usa pull quando:
• La velocità conta più della revisione manuale.
• Lavori in team piccoli con alto livello di fiducia.
• Le pipeline CI/CD risolvono automaticamente l'integrazione.
• Vuoi ridurre al minimo i passaggi manuali in progetti molto dinamici.

Considerazioni sulla collaborazione in team

La cultura del team e il tipo di progetto vanno considerati quando si decide quale approccio adottare.

In generale, puoi adottare due strategie diverse.

1. Strategia fetch-first: incoraggia comunicazione, code review e merge attento. Ideale per progetti open source o enterprise con standard rigorosi.
2. Strategia pull-first: massimizza l'agilità e riduce il tempo speso in merge manuali. Ideale per startup o team snelli in cui la velocità ha priorità rispetto a revisioni rigorose.

Best practice e precauzioni

Quando si lavora con i due comandi, gli sviluppatori tendono ad adottare alcune best practice per prevenire modifiche inattese al codice.

Ecco alcuni consigli da considerare:

• Fai commit prima del pull: salva sempre il tuo lavoro per evitare conflitti con modifiche non committate.
• Sfrutta il rebase: git pull --rebase aiuta a evitare storie disordinate.
• Fai il backup del tuo branch: crea un branch di sicurezza prima di pull importanti, soprattutto in progetti critici.
• Comunica con il team: assicurati che ci sia allineamento sul fatto che fetch-first o pull-first sia lo standard per evitare disallineamenti.
• Usa messaggi di commit descrittivi: soprattutto quando si creano commit di merge dopo un pull.
• Testa dopo il pull: esegui subito i test locali dopo il pull per intercettare rapidamente eventuale codice rotto.

Comandi correlati

Oltre all'accesso ai repository remoti, Git può essere usato anche per altri scopi per garantire un buon controllo di versione.

Ecco alcuni comandi comuni correlati:

• git diff HEAD..origin/main: confronta locale e remoto.
• git branch -a: ispeziona tutti i branch, locali e remoti.
• git clone: il punto di partenza per la sincronizzazione, crea una copia del repository remoto sulla tua macchina locale.

Altri comandi Git nella cheat sheet qui sotto.

Fonte: DataCamp Git Cheat Sheet

Automazione e scripting

Negli ambienti CI/CD, usare fetch e pull è comune.

L'automazione può essere abilitata tramite questi esempi:

• Fetch nei sistemi di build: assicura che i sistemi testino contro l'ultimo codice senza introdurre modifiche automaticamente.
• Automatizzare i pull con rebase: mantiene coerenti le storie di deploy e previene grafi di commit disordinati.
• Validazione post-fetch: esegui automaticamente test, linting o scansioni di sicurezza dopo la sincronizzazione.
• Fetch pianificati: alcuni team eseguono job di fetch regolari per mantenere aggiornati i mirror dei repository per strumenti di reportistica o auditing.

Workflow pratici e casi d'uso

I comandi Git sono potenti quando usati per gestire i workflow di sviluppo.

Possono quindi essere utilizzati al meglio nei seguenti casi d'uso:

• Workflow a branch di feature: gli sviluppatori fanno fetch per rivedere le modifiche remote prima di integrarle nel lavoro di feature in corso, assicurando che le feature si basino sull'ultima base.
• Backup e ripristino: il fetch assicura che lo stato remoto sia preservato localmente, dando ai team la possibilità di ripristinare i branch in caso di incidenti.
• Gestione dei rilasci: pull è utile quando si prepara un branch di rilascio che deve integrare rapidamente le ultime modifiche da main prima del deploy.
• Scenario hotfix: fetch ti consente di ispezionare patch urgenti senza rischiare il tuo branch locale finché non sei pronto a fare il merge.

Conclusione

Entrambi i comandi sono essenziali ma servono a scopi diversi. git fetch privilegia sicurezza, visibilità e integrazione controllata, mentre git pull privilegia velocità e comodità. La scelta tra i due dipende dal contesto: dimensione del progetto, cultura del team e bilanciamento tra stabilità e agilità.

I team dovrebbero trovare il giusto equilibrio tra l'uso di fetch per una revisione accurata e di pull per aggiornamenti rapidi. In questo modo potrai prevenire conflitti inutili, semplificare la collaborazione e mantenere repository più sani.

Vuoi saperne di più su come usare Git per il controllo di versione? Dai un'occhiata al nostro GitHub Foundations track o al nostro corso GitHub Concepts. Vuoi leggere altro su Git? Allora potrebbero esserti utili i nostri tutorial Git Push and Pull e Git Remote.