Rebase: cos'è, in cosa differisce da Merge e principio di funzionamento

Cos'è Rebase?

Rebase (rebasing) è un'operazione Git che sposta i commit dal branch corrente a un nuovo punto base. Invece di creare un commit di unione, rebase prende ogni commit dal branch sorgente e lo applica uno per uno sulla nuova base. Il risultato è una sequenza lineare di commit senza biforcazioni.

Il nome rebase deriva da “re-base” — cambiare la base. Mentre merge combina due branch in un unico punto, rebase sposta effettivamente l'intero branch in una nuova posizione, facendo sembrare che tu abbia iniziato lo sviluppo dallo stato corrente del branch di destinazione. Questo crea l'illusione di un lavoro perfettamente sequenziale.

Secondo Atlassian, 2025, i team che usano rebase per i branch di funzionalità spendono il 30% in meno di tempo nell'analisi della cronologia dei commit rispetto ai team che usano esclusivamente merge. La cronologia lineare semplifica git blame, bisect e la visualizzazione del log tramite git log --oneline.

Differenza fondamentale da Merge

Merge unisce i branch creando un commit con due genitori. Rebase riscrive la cronologia: vengono creati nuovi commit con nuovi hash, sebbene le loro modifiche siano identiche agli originali. Ciò significa che rebase cambia gli identificatori SHA dei commit, il che è critico per i branch pubblici.

Come funziona Rebase

Il meccanismo di rebase consiste in quattro passaggi: Git determina l'antenato comune (base di unione) del branch corrente e di destinazione, quindi applica sequenzialmente ogni commit del branch corrente sul branch di destinazione. Se si verifica un conflitto in qualsiasi passaggio, rebase si ferma e attende una risoluzione.

# Situazione iniziale: il branch feature è in ritardo di 3 commit rispetto a develop
git checkout feature/new-login
git rebase develop

# Git prende 3 commit da feature e li applica su develop
# Se non ci sono conflitti — rebase si completa automaticamente
# Se ci sono — Git si ferma sul commit in conflitto

Dopo rebase, il branch di funzionalità contiene tutti i commit di develop più i propri commit, che appaiono come una continuazione di develop. Ciò consente di unire in develop tramite fast-forward senza creare un commit di unione.

Processo passo dopo passo

Consideriamo un esempio dettagliato: uno sviluppatore ha creato un branch di funzionalità da develop, ha fatto due commit, mentre altri sviluppatori hanno aggiunto tre commit a develop. Rebase sposterà i due commit di funzionalità in una nuova posizione, creando le loro copie con nuovi SHA.

# 1. Creare un branch feature
git checkout -b feature/payment-refactor develop

# 2. Fare commit in feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Aggiornare develop (lavoro dei colleghi)
git checkout develop
git pull

# 4. Rebasare feature sul nuovo develop
git checkout feature/payment-refactor
git rebase develop

# 5. Ora feature può essere unita tramite fast-forward
git checkout develop
git merge feature/payment-refactor

Se si verifica un conflitto al passaggio 4, Git si ferma sul commit problematico. Lo sviluppatore risolve il conflitto, esegue git add e poi git rebase --continue. Per saltare un commit — git rebase --skip, per annullare l'intero rebase — git rebase --abort.

Salto automatico dei commit vuoti

Il flag --empty controlla il comportamento di rebase con i commit vuoti — situazioni in cui tutte le modifiche di un commit sono già presenti nel branch di destinazione. Per impostazione predefinita, rebase si ferma e chiede una decisione. Con --empty=drop, Git salta automaticamente questi commit senza fermarsi, accelerando il rebase massivo con un gran numero di commit.

Rebase interattivo

Il rebase interattivo (git rebase -i) è un potente strumento per modificare la cronologia dei commit. Apre un editor con un elenco di commit e comandi chiave: pick (mantieni), reword (cambia messaggio), edit (cambia contenuto), squash (unisci con il precedente), fixup (unisci senza messaggio), drop (elimina).

# Rebase interattivo degli ultimi 4 commit
git rebase -i HEAD~4

# L'editor aprirà un piano di rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Cambiamo in:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Risultato: tre commit (schermata di login, validazione, layout) vengono compressi in uno e il commit con i commenti viene eliminato. Ciò consente di presentare una cronologia pulita per la revisione del codice senza bozze e correzioni. Il rebase interattivo è uno strumento standard per preparare un branch di funzionalità prima di una Pull Request.

Rebase vs Merge: confronto

Rebase e Merge risolvono lo stesso problema — integrare le modifiche — ma in modi fondamentalmente diversi. La scelta tra di loro dipende dal tipo di cronologia che si desidera vedere in git log e da chi altro sta lavorando con il tuo branch.

Regola pratica: usa merge per l'integrazione in branch condivisi (develop, main) e rebase per aggiornare i branch di funzionalità personali. Molti team combinano entrambi: rebase della funzionalità su develop, poi --no-ff merge in develop.

Impatto su git bisect

Git bisect è uno strumento per trovare il commit che ha introdotto una regressione. Usando merge, git bisect attraversa correttamente i commit di unione considerando entrambi i genitori. Con rebase, bisect funziona più velocemente perché la cronologia è lineare e non richiede biforcazioni. Tuttavia, se rebase è stato eseguito dopo che i commit sono diventati noti al team, gli SHA originali vengono persi e bisect potrebbe non trovare il commit problematico.

Quando usare Rebase

Rebase è ottimale in tre scenari: preparare un branch di funzionalità per una Pull Request, aggiornare un branch personale allo stato corrente di main/develop e pulire la cronologia prima dell'unione. In ogni caso, rebase migliora la leggibilità della cronologia senza rischi per il lavoro di squadra.

Prima di una Pull Request, si consiglia di eseguire un rebase interattivo per combinare i commit di bozza (WIP, correzioni post-revisione) in unità logiche significative. Ciò facilita la revisione del codice: il revisore vede non 15 commit minori ma 3-5 modifiche strutturate con messaggi chiari.

Per aggiornare un branch di funzionalità, rebase è preferibile a merge perché non crea commit di unione non necessari. Se esegui periodicamente git rebase develop all'interno del branch di funzionalità, l'unione finale non avrà una cascata di 10 commit di unione — solo commit puliti della funzionalità su develop.

La pulizia della cronologia tramite rebase interattivo prima dell'unione consente di nascondere correzioni minori (errori di battitura, formattazione) e raggruppare i commit per funzionalità. I messaggi Git dovrebbero seguire la convenzione Conventional Commits (fix:, feat:, refactor:, docs:), che genera un changelog automatico.

Rischi e regole di Rebase

Rebase è un'operazione pericolosa se applicata in modo errato. Il rischio principale è riscrivere la cronologia pubblicata. Se uno sviluppatore rebasa un branch che altri hanno già pushato e stanno usando, le loro copie locali si desincronizzeranno e dovranno eseguire un force-pull con il rischio di perdita di dati.

• Regola d'oro: non fare mai rebase di commit che già esistono nel repository condiviso. Questo vale per qualsiasi branch accessibile da altri membri del team
• Force push: dopo il rebase di un branch di funzionalità locale, è necessario un push con il flag --force-with-lease, più sicuro di --force perché verifica se qualcuno ha aggiornato il branch sul server
• Perdita di contesto: rebase distrugge le informazioni su quando e da quale branch è stato creato il branch di funzionalità. Se preservare le date di creazione del branch è importante, usa merge
• Conflitti: durante rebase, i conflitti devono essere risolti per ogni commit individualmente, il che può essere noioso con un gran numero di commit

Per minimizzare i rischi, segui questa regola: rebase solo per branch personali che non sono stati pubblicati. Se un branch è già nel repository condiviso, usa merge con --no-ff. Se devi rebasare un branch pubblicato, avvisa il team e coordina il force push in anticipo.

La protezione automatica contro il rebase pericoloso è implementata tramite hook lato server: un hook pre-receive sul server Git può verificare se il push riscrive commit pubblicati. GitHub e GitLab forniscono protezione integrata per i branch protetti — il force push viene bloccato a meno che la protezione non venga rimossa da un amministratore.