Når og hvordan bør du skrive Git-historikken på nytt?

Question

Accepted Answer

Git lar deg **skrive historikken på nytt** — endre, rebasere, squashe eller fjerne commits — for å rydde opp i commits eller fikse problemer. Det er kraftig men må gjøres forsiktig: omskriving av **delt** historikk forårsaker alvorlige problemer, så reglene rundt det er kritiske. ## Måter å skrive historikken på nytt ```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 gylne regelen ```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 brukstilfeller for omskriving (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 må skrive delt historikk på nytt (sjeldent) ```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 er viktig Å forstå når og hvordan du skal skrive Git-historikken på nytt er viktig kunnskap på senior-nivå fordi omskriving av historikk er **kraftig men farlig**, og å forstå reglene — spesielt rundt delt historikk — forhindrer alvorlige problemer og muliggjør legitim opprydding. Å kjenne **måtene å skrive på nytt** (endre siste commit med amend, interaktiv rebasering for squashing/omformulering/omordning, rebasering for lineær historikk, reset, filter-repo for storskalerte endringer) og at de alle **endrer commit-hasher** (oppretter nye commits) er grunnlaget. Mest kritisk er det å forstå **den gylne regelen — aldri skriv delt/pushet historikk på nytt** — essensielt fordi omskriving endrer hasher, noe som får historikken din til å divergere fra samarbeidspartnernes (som fortsatt har de gamle commits), noe som fører til duplikater, konflikter og smertefull avstemming; omskriving av delt historikk er en alvorlig forstyrrelse som denne regelen forhindrer, med **revert** (en sikker ny angre-commit) som den riktige tilnærmingen for delte grener i stedet. Å forstå de **legitime lokale brukstilfellene** (rydding av WIP-commits før en PR, endring av feil før pushing, rebasering for å holde lineærtitet før deling — alt på lokale, upushete commits) klargjør når omskriving er passende og verdifull. En kritisk sikkerhetsnuanse: hvis en **hemmelighet ble committed og pushet**, er omskriving av historikken for å fjerne den utilstrekkelig — hemmeligheten er allerede eksponert og må **roteres** (et viktig punkt i den virkelige verden når det gjelder sikkerhet). Å vite hvordan man **håndterer den sjeldne nødvendige omskrivingen av delt historikk** (teamkoordinering, `--force-with-lease` i stedet for `--force`, alle re-synkroniserer) reflekterer moden dømmekraft. Ettersom omskriving av historikk er kraftig men forårsaker alvorlige problemer når det misbrukes på delt historikk, og ettersom forståelse av den gylne regelen, legitime brukstilfeller og sikre praksis er essensielt for å bruke det ansvarlig, er forståelse av når og hvordan du skal skrive Git-historikken på nytt viktig kunnskap på senior-nivå — et emne der forståelse av sikkerhetreglene (spesielt aldri omskriving av delt historikk) forhindrer ekte samarbeidskatastrofer, og reflekterer den dømmekraften som forventes for seniorroller som arbeider med Git i team.