Rebase interattivo: squash, fixup, reword, drop

Il rebase interattivo è l’editor della tua storia locale. Ti permette di rinominare commit, unirli, eliminarli, riordinarli o fermarti a metà per modificarli.

Non serve a nascondere errori. Serve a trasformare una sequenza di lavoro grezza in una storia leggibile per review e manutenzione.

Perché questa lezione conta

Durante lo sviluppo fai commit intermedi: wip, fix lint, prova, aggiusta test. Sono utili mentre lavori, ma non sempre utili nella storia finale.

Prima di aprire una PR, puoi ripulire il branch in commit logici: uno per modello dati, uno per UI, uno per test, ad esempio.

Obiettivo operativo

Alla fine della lezione devi saper usare git rebase -i, scegliere tra pick, reword, squash, fixup, drop, e sapere quando non riscrivere.

Avvio

Per riscrivere gli ultimi 5 commit:

git rebase -i HEAD~5

Git apre un editor:

pick a1b2c3d feat: aggiungi form login
pick b2c3d4e wip
pick c3d4e5f fix typo
pick d4e5f6a test: copri login
pick e5f6a7b docs: aggiorna readme

Modifichi le parole a sinistra, salvi e Git applica il piano.

Comandi principali

pick. Mantieni il commit.

reword. Mantieni il contenuto, cambia messaggio.

squash. Unisci al commit precedente e combina messaggi.

fixup. Unisci al commit precedente scartando il messaggio del commit fixup.

drop. Elimina il commit.

edit. Fermati su quel commit per modificarne contenuto.

exec. Esegui un comando durante il rebase, ad esempio test.

Esempio

pick a1b2c3d feat: aggiungi form login
fixup b2c3d4e wip
fixup c3d4e5f fix typo
pick d4e5f6a test: copri login
reword e5f6a7b docs: aggiorna readme

Risultato: meno rumore, commit ancora significativi.

Autosquash

Puoi creare commit fixup mirati:

git commit --fixup <sha>
git rebase -i --autosquash main

Git posiziona automaticamente i fixup vicino al commit corretto. È molto utile durante review: correggi un commento senza pensare subito alla pulizia finale.

Quando usarlo

Usalo su:

1. branch locale;
2. branch personale;
3. PR prima del merge, se il team accetta force push;
4. commit WIP non ancora condivisi.

Non usarlo su:

1. main;
2. branch condivisi;
3. release branch pubblici;
4. storia già usata da altri.

Prima di iniziare

Controlli:

git status -sb
git log --oneline --decorate -10
git branch backup-prima-rebase

Il branch backup costa quasi nulla e ti permette di tornare indietro.

Recupero

Se durante il rebase sei confuso:

git rebase --abort

Se hai finito ma il risultato non va:

git reflog
git reset --hard <sha-prima-rebase>

Il reflog è la rete di sicurezza.

Laboratorio guidato

Crea 8 commit:

1. feature iniziale;
2. fix typo;
3. test;
4. wip;
5. refactor;
6. fix lint;
7. docs;
8. correzione test.

Riducili a 4 commit logici:

1. feature;
2. refactor;
3. test;
4. docs.

Verifica con git log --oneline.

Output atteso

Una PR con storia leggibile e una nota:

Ho usato rebase interattivo solo sul branch personale.
Ho mantenuto commit utili per review e bisect.
Ho squashato solo rumore operativo.

Errori comuni

Squashare tutto sempre. A volte commit separati aiutano review e bisect.

Droppare commit senza leggere il diff. Puoi eliminare lavoro reale.

Riscrivere branch condivisi. È il rischio principale.

Fare rebase con working tree sporco. Parti sempre da stato pulito o salva il lavoro.

Checklist di verifica

• so usare pick, reword, squash, fixup, drop;
• so creare backup branch prima;
• so usare --abort;
• so recuperare con reflog;
• so decidere quali commit meritano di restare separati.

Collegamenti

• Modulo: Riscrivere la storia: rebase, amend, cherry-pick — lezione 18 del corso.
• Conventional Commits e PR workflow rendono questa pulizia più utile.