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.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona