Interactieve rebase (git rebase -i) stelt je in staat om commits herschrijven, opnieuw ordenen, combineren, bewerken of verwijderen — waardoor je je commit-history opschonen kunt vóórdat je deze deelt. Het is een krachtig hulpmiddel voor het creëren van een schone, logische history uit chaotische work-in-progress commits.
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
Je bewerkt de lijst — je kiest een actie per commit (en het opnieuw ordenen van regels sorteert commits opnieuw) — en Git herhaalt ze vervolgens dienovereenkomstig.
✓ 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
Het begrijpen van interactieve rebase is waardevol voor het creëren van schone commit-history, dus het is praktische kennis die nuttig is voor professioneel Git-werk.
Tijdens ontwikkeling zijn commits vaak chaotisch — work-in-progress commits met berichten als "wip", "fix typo", "oops", debug commits en een niet-logische volgorde — en interactieve rebase stelt je in staat om dit op te schonen vóórdat je het deelt: het samenvoegen van meerdere chaotische commits in schone logische, het herformuleren van slechte berichten, het opnieuw ordenen van commits in een zinvolle volgorde, het verwijderen van ongewenste commits (zoals debug code) en het opsplitsen van commits — waardoor je chaotische development-history wordt omgezet in een schone, logische, reviewbare reeks.
Dit is belangrijk omdat schone commit-history (zoals behandeld in best practices voor commits) code review gemakkelijker maakt, history begrijpelijker en debugging (via bisect) effectiever — dus het vermogen om alles op te ruimen vóórdat anderen je werk zien, is een kenmerk van professioneel Git-gebruik.
Het begrijpen van de acties (pick, squash, fixup, reword, edit, drop en opnieuw ordenen) en veelvoorkomende toepassingen (vooral het samenvoegen van WIP commits, een zeer frequent noodzakelijk iets) is de praktische vaardigheid.
Kritisch is dat de gouden regel van rebasing nog steeds van toepassing is — interactieve rebase herschrijft history (nieuwe hashes), dus dit mag alleen worden gedaan op lokale, niet-gepushte commits (nooit op gedeelde history), waarbij het typische gebruik het opschonen van een feature branch vóórdat je pusht of een pull request opent.
Omdat schone, logische commit-history waardevol is voor samenwerking en onderhoudbaarheid, en omdat development natuurlijk chaotische commits oplevert die interactieve rebase kan opschonen vóórdat het wordt gedeeld (veilig, op lokale commits), is het begrijpen van interactieve rebase — de acties, veelvoorkomende toepassingen als samenvoegen, en de veiligheidregel — waardevol, praktisch relevant Git-kennis voor professionele ontwikkeling, een krachtig hulpmiddel voor het presenteren van schone, reviewbare history dat doordachte Git-gebruikers onderscheidt, routinematig gebruikt om werk op te poetsen vóórdat het met het team wordt gedeeld.