Hvornår og hvordan bør du omskrive Git-historie?

Question

Accepted Answer

Git lader dig **omskrive historie** — ændre, rebasere, squashe eller fjerne commits — for at rydde op i commits eller løse problemer. Det er kraftfuldt, men skal gøres med forsigtighed: omskrivning af **delt** historie forårsager alvorlige problemer, så reglerne omkring det er kritiske. ## Måder at omskrive historie på ```text git commit --amend → modify the most recent commit (message or content) git rebase -i → squash, reword, reorder, edit, drop commits (interactive) git rebase → replay commits onto another base (linear history) git reset → move the branch pointer (discard/uncommit) git filter-repo → rewrite MANY commits (remove a file/secret from all history) → All of these change commit HASHES (rewriting = creating new, different commits). ``` ## Den gyldne regel ```text ⚠️ NEVER rewrite history that has been PUSHED/SHARED (that others may have): → rewriting changes commit hashes → your history DIVERGES from collaborators' → they'll have the old commits; pulls create duplicates/conflicts; chaos ensues → forces everyone to painfully reconcile → a serious disruption ✓ Rewrite ONLY local, unpushed commits (cleanup before sharing). ✗ On shared branches → use REVERT (a new undoing commit) instead, which is safe. ``` ## Legitime anvendelser af omskrivning (lokal) ```text ✓ Clean up messy WIP commits before opening a PR (squash, reword) → clean history ✓ Fix a mistake in the last commit (amend) before pushing ✓ Keep a feature branch linear/up-to-date with main (rebase) before sharing ✓ Remove a SECRET accidentally committed (filter-repo) — though if it was PUSHED, the secret must be ROTATED (it's already exposed; rewriting alone isn't enough) ``` ## Hvis du skal omskrive delt historie (sjælden) ```text → COORDINATE with the whole team (everyone stops, re-syncs) → Force-push carefully: git push --force-with-lease (safer than --force — checks first) → Everyone must reset/re-clone to the rewritten history → Do this only when truly necessary (e.g. purging a leaked secret) and with agreement. ``` ## Hvorfor det betyder noget At forstå hvornår og hvordan man omskriver Git-historie er vigtig vidensressource på seniorplan, fordi historieomskrivning er **kraftfuld men farlig**, og forståelse af reglerne — især omkring delt historie — forhindrer alvorlige problemer samtidig med at muliggøre legitim oprydning. At kende **måder at omskrive på** (amend for det sidste commit, interaktiv rebase til squashing/genudformulering/omordning, rebase til lineær historie, reset, filter-repo til storskalerede ændringer) og at de alle **ændrer commit-hashes** (opretter nye commits) er grundlaget. Mest kritisk er det at forstå den **gyldne regel — aldrig omskrive delt/pushed historie** — essentielt fordi omskrivning ændrer hashes, hvilket får din historie til at divergere fra samarbejdernes (som stadig har de gamle commits), hvilket fører til dubletbitter, konflikter og smertefull forsoningstid; omskrivning af delt historie er en alvorlig afbrydelse som denne regel forhindrer, hvor **revert** (et sikkert nyt fortrydelsescommit) er den korrekte tilgang til delte branches i stedet. At forstå de **legitime lokale anvendelser** (oprydning af WIP-commits før en PR, ændring af fejl før pushing, rebasering for at blive lineær før deling — alt på lokale, unpushed commits) præciserer hvornår omskrivning er passende og værdifuld. Et afgørende sikkerhedsnuance: hvis en **hemmelighed blev committed og pushed**, er omskrivning af historie for at fjerne den utilstrækkelig — hemmeligheden er allerede eksponeret og skal **roteres** (et vigtigt virkelighedskontekst sikkerhedspunkt). At vide hvordan man **håndterer den sjældne nødvendige omskrivning af delt historie** (teamkoordinering, `--force-with-lease` snarere end `--force`, alle re-synker) afspejler moden dømmekraft. Fordi historieomskrivning er kraftfuld men forårsager alvorlige problemer når den misbruges på delt historie, og fordi forståelse af den gyldne regel, legitime anvendelser og sikre praksisser er essentiel for at bruge den ansvarsfuldt, er forståelse af hvornår og hvordan man omskriver Git-historie vigtig vidensressource på seniorplan — et emne hvor forståelse af sikkerhedsreglerne (især aldrig omskrive delt historie) forhindrer reelle samarbejdskatastrof, hvilket afspejler den dømmekraft som forventes for seniorrollen arbejder med Git på hold.