Git rebase vs merge: differenze pratiche e quando usare ciascuno

Lavori su un ramo feature da due giorni. Hai cinque commit. Arriva il momento di integrare i cambiamenti in main. Senti parlare di merge e rebase, ma non hai mai capito la differenza pratica. Risultato? Usi sempre merge, e la cronologia del repository finisce per sembrare un piatto di spaghetti. Oppure provi rebase, perdi un commit e ti ritrovi a urlare contro il terminale.

No, non sei tu il problema. Il problema è che merge e rebase rispondono a esigenze diverse, e senza capire il "perché" dietro ciascuno, si sbaglia quasi sempre. Noi, di Meteora Web, gestiamo repository con Laravel, Vue e progetti WordPress ogni giorno. Abbiamo visto storie di successo e disastri. In questa guida ti spieghiamo la differenza concreta, quando usare l'uno o l'altro, e come non rompere niente.

Il cuore del problema: cronologia lineare vs cronologia fedele

Immagina di essere un detective che deve ricostruire la storia di un progetto. La cronologia dei commit è la tua unica traccia. Il merge registra fedelmente ogni diramazione e ricongiunzione, con un commit speciale (merge commit) che ha due genitori. È come un diario con note a margine: racconta la verità, ma è faticoso da leggere. Il rebase, invece, riscrive la storia per farla sembrare lineare: prende i tuoi commit e li "riapplica" uno sopra l'altro sulla testa del ramo di destinazione, come se avessi lavorato sempre sull'ultima versione.

La domanda non è quale sia meglio in assoluto, ma quale sia meglio per chi leggerà quella cronologia dopo di te.

Merge: il diario onesto (ma disordinato)

Quando fai git merge feature main, Git crea un nuovo commit (merge commit) che collega due linee di sviluppo. La cronologia conserva tutti i rami e le biforcazioni. È trasparente, ma può diventare caotica se usi spesso i rami.

git checkout main
# Assicurati di essere aggiornato
git pull origin main
# Unisci il ramo feature
git merge feature
# Git crea un merge commit (se non è fast-forward)

Quando usarlo: su rami condivisi (main, develop, release) o quando vuoi preservare esattamente quando e come è nato un ramo. La cronologia "storica" è importante per audit o rilasci.

Rebase: la cronologia lineare (ma attento a non riscriverla in pubblico)

Con git rebase main mentre sei sul ramo feature, Git prende i tuoi commit, li mette da parte, sposta il ramo feature sulla punta di main, e poi riapplica i tuoi commit uno per uno. Il risultato è una sequenza lineare, come se avessi iniziato a lavorare dopo l'ultimo commit di main.

git checkout feature
# Riscrivi la cronologia dei tuoi commit sulla base di main
git rebase main
# Ora feature sembra essere partita dall'ultimo commit di main

Quando usarlo: su rami locali non ancora condivisi, prima di fare merge in main, per mantenere una cronologia pulita. Ottimo per feature branch personali o per preparare una pull request ordinata.

Errori comuni (e come evitarli)

Abbiamo visto tre scenari tipici in cui la scelta sbagliata causa mal di testa.

1. Rebase su un ramo condiviso con altri

Hai fatto rebase su un ramo su cui stavano lavorando anche Alice e Bob. Ora i loro repository locali puntano a commit vecchi. Quando loro provano a fare push, Git rifiuta perché la cronologia non corrisponde. Soluzione? Mai fare rebase su rami pubblici (main, develop, o branch su cui altri hanno già fatto pull).

2. Merge senza logica (merge-commit a pioggia)

Ogni volta che aggiorni il tuo branch locale da main fai merge. Dopo 10 volte hai 10 merge commit inutili. Meglio fare rebase del tuo feature branch su main prima di un unico merge finale.

3. Rebase interattivo e conflitti mal gestiti

Usi git rebase -i per riordinare o squashare commit. Arrivano conflitti. Invece di risolverli con calma, abortisci e perdi tutto. Ricorda: git rebase --abort ti riporta allo stato iniziale. Sei al sicuro.

La scelta pratica: regole che applichiamo noi

Noi, di Meteora Web, abbiamo una strategia semplice che funziona su progetti con team fino a 10 persone.

Per i rami di integrazione (main, develop, staging): solo merge con --no-ff (merge commit esplicito). Così ogni rilascio è un punto visibile nella cronologia.

Per i rami feature personali prima di una pull request: rebase sul ramo di destinazione, poi squash dei commit in uno solo (o pochi) con git rebase -i. La PR arriva con un unico commit pulito.

Per aggiornare il tuo feature branch con i cambiamenti di main mentre lavori: rebase (non merge). Così eviti merge commit inutili e mantieni la cronologia lineare.

# Mentre sei su feature
git fetch origin
git rebase origin/main
# Se ci sono conflitti, risolvili e git rebase --continue

Operativamente: una checklist per ogni situazione

Ecco una guida passo-passo per decidere.

1. Questo ramo è pubblico? (altri hanno già fatto pull) Sì → usa merge. No → vai al punto 2.
2. Devo integrare il mio lavoro in un ramo principale? Sì → fai rebase del tuo ramo su main, poi fai merge (con --no-ff).
3. Devo solo tenere aggiornato il mio ramo locale con main? Rebase.
4. Voglio preservare la cronologia esatta dei rami per motivi di audit? Merge.

Questa checklist evita il 90% dei problemi che vediamo nei team che seguiamo.

In sintesi — cosa fare

1. Impara a usare entrambi: sono strumenti, non fedi. Prova rebase in un repository di test finché non ti senti sicuro.
2. Stabilisci una policy di team: decide una volta per tutte cosa usare per feature branch, main, e hotfix. Noi, ad esempio, usiamo rebase per feature locali e merge per release.
3. Mai riscrivere la storia pubblica: se un ramo è stato pushato e altri lo hanno visto, vieta il rebase.
4. Usa rebase interattivo per pulire i commit prima di una PR: git rebase -i HEAD~N per squashare, riordinare, modificare messaggi.
5. Fai un backup con un branch prima di operazioni rischiose: git branch backup-feature prima di rebase su un ramo importante.

Adesso tocca a te. Apri il terminale, crea un repository di prova con due branch, e prova entrambi i comandi. La differenza la capisci solo con le mani. Noi ci siamo passati e possiamo dirti che una volta che padroneggi rebase, non torni più indietro.