Interaktiv rebase (git rebase -i) lar deg omskrive, endre rekkefølge på, kombinere, redigere eller slette commits — rydde opp i commit-historikken før du deler den. Det er et kraftig verktøy for å lage ren, logisk historie fra rotete arbeid-i-gang commits.
git rebase -i HEAD~4 # interactively rebase the last 4 commits
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
Du redigerer listen — velger en handling per commit (og omlegging av linjer endrer rekkefølgen på commits) — deretter gjenskaper Git dem deretter.
✓ 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
Å forstå interaktiv rebase er verdifullt for å lage ren commit-historie, så det er nyttig praktisk kunnskap for profesjonelt Git-arbeid.
Under utvikling er commits ofte rotete — arbeid-i-gang commits med meldinger som "wip", "fix typo", "oops", debug-commits og en ikke-logisk rekkefølge — og interaktiv rebase lar deg rydde opp i dette før du deler det: skvise sammen flere rotete commits til rene logiske, omskrive dårlige meldinger, endre rekkefølgen på commits til en fornuftig sekvens, slette uønskede commits (som debug-kode) og dele commits — transformere rotete utviklingshistorie til en ren, logisk, gjennomgjengelig sekvens.
Dette betyr noe fordi ren commit-historie (som dekket i god commit-praksis) gjør kodegjennomgang lettere, historie mer forståelig og debugging (via bisect) mer effektiv — så evnen til å rydde opp før andre ser arbeidet ditt er et kjennetegn på profesjonell Git-praksis.
Å forstå handlingene (pick, squash, fixup, reword, edit, drop, og omlegging) og vanlige brukstilfeller (spesielt skvising av WIP-commits, et veldig hyppig behov) er den praktiske ferdigheten.
Kritisk sett gjelder den gylne regelen for rebase fremdeles — interaktiv rebase omskriver historie (nye hashes), så det må bare gjøres på lokale, ikke-pushede commits (aldri på delt historie), med typisk bruk å rydde opp i en funksjonsgren før pushing eller åpning av en pull request.
Siden ren, logisk commit-historie er verdifull for samarbeid og vedlikeholdbarhet, og siden utvikling naturlig produserer rotete commits som interaktiv rebase kan rydde opp i før deling (sikkert, på lokale commits), er forståelse av interaktiv rebase — handlingene, vanlige brukstilfeller som skvising, og sikkerheetsregelen — verdifull, praktisk relevant Git-kunnskap for profesjonell utvikling, et kraftig verktøy for å presentere ren, gjennomgjengelig historie som skiller gjennomtenkte Git-brukere, brukt rutinemessig til å polere arbeid før det deles med teamet.