16. Merge vs Rebase

Merge e rebase risolvono lo stesso problema: integrare le modifiche di un branch in un altro — ma con effetti molto diversi sulla history.

16.1 L’opzione merge

Per riportare le modifiche di main su feature si crea un merge commit su feature che lega insieme i due branch:

git checkout feature
git merge main

• ✅ Non distruttivo: commit e modifiche preesistenti non vengono alterati.
• ❌ Ogni integrazione aggiunge un merge commit “estraneo”; se feature vive a lungo e main cambia di frequente, la cronologia diventa difficile da leggere.

16.2 L’opzione rebase

L’intero branch feature viene spostato in punta a main, ricreando i singoli commit come nuovi:

git checkout feature
git rebase main

• ✅ History lineare e più leggibile: nessun merge commit.
• ❌ Si perde l’informazione su quando le modifiche di main sono state incorporate; e occorre rispettare la regola d’oro:

Regola d’oro del rebase: mai fare rebase su un branch pubblico.

Il rebase crea commit “nuovi di zecca”: Git considererà il proprio main discostato dal remote e il push normale verrà rifiutato — serve --force. Gli altri collaboratori avrebbero ancora il main originale e non riuscirebbero a sincronizzarsi facilmente.

Come tutte le regole d’oro, può avere eccezioni concordate col team: ad esempio riscrivere la history di un feature branch pubblicato prima del merge sul principale, per risolvere in anticipo i conflitti direttamente nei commit — a patto di verificare che il risultato resti funzionante.