När och hur bör du skriva om Git-historik?

Question

Accepted Answer

Git låter dig **skriva om historik** — ändra, rebasera, squasha eller ta bort commits — för att städa upp commits eller fixa problem. Det är kraftfullt men måste göras försiktigt: att skriva om **delad** historik orsakar allvarliga problem, så reglerna omkring det är kritiska. ## Sätt att skriva om historik ```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 gyllene regeln ```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. ``` ## Legitima användningar av att skriva om (lokalt) ```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) ``` ## Om du måste skriva om delad historik (sällsynt) ```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. ``` ## Varför det är viktigt Att förstå när och hur man skriver om Git-historik är viktig kunskap på seniornivå eftersom att skriva om historik är **kraftfullt men farligt**, och att förstå reglerna — särskilt runt delad historik — förhindrar allvarliga problem samtidigt som det möjliggör legitim städning. Att kunna **sätten att skriva om** (ändra för senaste commit, interaktiv rebase för squashing/omskrivning/omordning, rebase för linjär historik, reset, filter-repo för storskaliga ändringar) och att de alla **ändrar commit-hashvärden** (skapar nya commits) är grunden. Mest kritiskt är att förstå den **gyllene regeln — skriv aldrig om delad/pushad historik** — väsentlig eftersom att skriva om ändrar hashvärden, vilket får din historik att avvika från kollegors (som fortfarande har gamla commits), ledande till dubbletter, konflikter och smärtsam avstämning; att skriva om delad historik är en allvarlig störning som denna regel förhindrar, där **revert** (ett säkert nytt undocommit) är det korrekta tillvagagångssättet för delade grenar istället. Att förstå de **legitima lokala användningarna** (städa upp WIP-commits innan en PR, rätta till misstag innan pushing, rebasera för att hålla linjär innan delning — allt på lokala, opushade commits) förtydligar när omskrivning är lämplig och värdefull. En viktig säkerhetsnuans: om en **hemlighet commitades och pushades** är att skriva om historik för att ta bort den otillräcklig — hemligheten är redan exponerad och måste **roteras** (en viktig verklig säkerhetspunkt). Att veta hur man **hanterar den sällsynta nödvändiga omskrivningen av delad historik** (teamsamordning, `--force-with-lease` snarare än `--force`, alla synkar igen) återspeglar mogna omdömen. Eftersom att skriva om historik är kraftfullt men orsakar allvarliga problem när det missbrukas på delad historik, och eftersom att förstå den gyllene regeln, legitima användningar och säker praxis är väsentligt för att använda det ansvarsfullt, är förståelse för när och hur man skriver om Git-historik viktig kunskap på seniornivå — ett ämne där förståelse för säkerhetreglerna (särskilt aldrig skriva om delad historik) förhindrar verkliga samarbetskatastrofer, vilket återspeglar den omdömeskraft som förväntas för seniorer som arbetar med Git i team.