Hvordan fungerer interaktiv rebase?

Question

Accepted Answer

**Interaktiv rebase** (`git rebase -i`) lader dig **omskrive, omarrangere, kombinere, redigere eller slette commits** — og rydde op i dit commit-historik før du deler det. Det er et kraftfuldt værktøj til at skabe rent, logisk historik fra rodet arbejds-i-gang commits. ## Start af interaktiv rebase ```bash git rebase -i HEAD~4 # interactively rebase the last 4 commits git rebase -i # rebase commits after # → opens an editor listing the commits with actions to apply ``` ## Handlingerne ```text 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 — vælger en handling per commit (og omarrangering af linjer omarrangerer commits) — hvorefter Git genskaber dem accordingly. ## Almindelige anvendelser ```text ✓ 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. ``` ## Den gyldne regel gælder stadig ```text ⚠️ 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 ``` ## Hvorfor det betyder noget At forstå interaktiv rebase er værdifuldt for **at skabe rent commit-historik**, så det er praktisk nyttig viden til professionelt Git-arbejde. Under udvikling er commits ofte rodet — arbejds-i-gang commits med beskeder som "wip", "fix typo", "oops", debug commits og ikke-logisk rækkefølge — og **interaktiv rebase** lader dig **rydde op før deling**: kombinere flere rotet commits til rene logiske, omformulere dårlige beskeder, omarrangere commits i en fornuftig rækkefølge, slette uønskede commits (som debug-kode) og opdele commits — transformere rotet udviklings-historik til en ren, logisk, gennemsynelig sekvens. Det betyder noget, fordi rent commit-historik (som dækket i god-commit-praksis) gør kodegennemgang nemmere, historik mere forståelig og debugging (via bisect) mere effektiv — så evnen til at rydde op før andre ser dit arbejde er et kendetegn på professionel Git-praksis. At forstå **handlingerne** (pick, squash, fixup, reword, edit, drop og omarrangering) og **almindelige anvendelser** (især kombinering af WIP commits, et meget hyppigt behov) er den praktiske færdighed. Vigtigst af alt gælder **den gyldne regel for rebase stadig** — interaktiv rebase omskriver historik (nye hashes), så det må kun gøres på **lokale, ikke-pushede commits** (aldrig på delt historik), med den typiske anvendelse værende oprydning af en feature branch *før* pushing eller åbning af en pull request. Da rent, logisk commit-historik er værdifuldt for samarbejde og vedligeholdelse, og da udvikling naturligt producerer rotet commits, som interaktiv rebase kan rydde op i før deling (sikkert, på lokale commits), er forståelse af interaktiv rebase — handlingerne, almindelige anvendelser som kombinering og sikkerhedsreglen — værdifuld, praktisk relevant Git-viden til professionel udvikling, et kraftfuldt værktøj til at præsentere ren, gennemsynelig historik, der adskiller tankefulde Git-brugere og bruges rutinemæssigt til at polere arbejde før det deles med teamet.