Il rebase interattivo (git rebase -i) ti permette di riscrivere, riordinare, combinare, modificare o eliminare commit — pulendo la cronologia dei tuoi commit prima di condividerla. È uno strumento potente per creare una cronologia pulita e logica a partire da commit disordinati e in corso di elaborazione.
git rebase -i HEAD~4
git rebase -i <commit>
pick abc123 Add login form # keep the commit as-is
squash def456 Fix typo # COMBINE into the previous commit (merge messages)
fixup ghi789 Fix another typo # combine into previous, DISCARD this message
reword jkl012 Add validation # keep the commit but EDIT its message
edit mno345 Refactor auth # PAUSE to amend the commit (change content)
drop pqr678 Debug logging # DELETE this commit entirely
# reorder lines to REORDER commits
Modifichi l'elenco — scegliendo un'azione per ogni commit (e il riordinamento delle righe riordina i commit) — e Git poi li riproduce di conseguenza.
✓ SQUASH multiple WIP commits into one clean commit ("wip", "fix", "oops" → one good commit)
✓ REWORD bad commit messages
✓ REORDER commits into a logical sequence
✓ DROP unwanted commits (debug code, mistakes)
✓ SPLIT a commit (via edit) into smaller commits
→ Result: a clean, logical history instead of messy development commits.
⚠️ Interactive rebase REWRITES history (new commit hashes):
→ only do it on LOCAL, UNPUSHED commits — never on shared/public history
→ typical use: clean up your feature branch BEFORE pushing/opening a PR
Comprendere il rebase interattivo è prezioso per creare una cronologia di commit pulita, quindi è una conoscenza pratica utile per il lavoro professionale con Git.
Durante lo sviluppo, i commit sono spesso disordinati — commit in corso di elaborazione con messaggi come "wip", "fix typo", "oops", commit di debug e in ordine non logico — e il rebase interattivo ti permette di pulire tutto questo prima di condividere: combinando più commit disordinati in commit logici e puliti, riformulando messaggi scarsi, riordinando i commit in una sequenza sensata, eliminando commit indesiderati (come codice di debug) e dividendo commit — trasformando la cronologia di sviluppo disordinata in una sequenza pulita, logica e revisionabile.
Ciò è importante perché una cronologia di commit pulita (come trattato nelle buone pratiche di commit) rende la revisione del codice più facile, la cronologia più comprensibile e il debug (tramite bisect) più efficace — quindi la capacità di mettere in ordine prima che altri vedano il tuo lavoro è un segno distintivo della pratica professionale di Git.
Comprendere le azioni (pick, squash, fixup, reword, edit, drop e riordinamento) e gli usi comuni (in particolare lo squashing di commit WIP, un'esigenza molto frequente) è l'abilità pratica.
Criticamente, la regola d'oro del rebasing continua a valere — il rebase interattivo riscrive la cronologia (nuovi hash), quindi deve essere eseguito solo su commit locali e non pushati (mai su cronologia condivisa), con l'uso tipico che consiste nel pulire un ramo di feature prima di pushare o aprire una pull request.
Poiché una cronologia di commit pulita e logica è preziosa per la collaborazione e la manutenibilità, e poiché lo sviluppo produce naturalmente commit disordinati che il rebase interattivo può pulire prima di condividere (in sicurezza, su commit locali), comprendere il rebase interattivo — le azioni, gli usi comuni come lo squashing e la regola di sicurezza — è una conoscenza Git pratica e rilevante per lo sviluppo professionale, uno strumento potente per presentare una cronologia pulita e revisionabile che distingue gli utenti di Git consapevoli, utilizzato regolarmente per perfezionare il lavoro prima che sia condiviso con il team.