Wanneer en hoe moet je Git-geschiedenis herschrijven?

Question

Accepted Answer

Git stelt je in staat om **geschiedenis herschrijven** — commits aanpassen, rebasing, squashing, of verwijderen — om commits op te schonen of problemen op te lossen. Het is krachtig maar moet voorzichtig gedaan worden: het herschrijven van **gedeelde** geschiedenis veroorzaakt ernstige problemen, dus de regels daaromheen zijn kritiek. ## Manieren om geschiedenis herschrijven ```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). ``` ## De gouden 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. ``` ## Legitieme toepassingen van herschrijven (lokaal) ```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) ``` ## Als je gedeelde geschiedenis moet herschrijven (zeldzaam) ```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. ``` ## Waarom het belangrijk is Begrijpen wanneer en hoe je Git-geschiedenis moet herschrijven is belangrijk kennis op senior-niveau omdat geschiedenis herschrijven **krachtig maar gevaarlijk** is, en het begrijpen van de regels — vooral rond gedeelde geschiedenis — voorkomt ernstige problemen en maakt legitieme opschoning mogelijk. Het kennen van de **manieren om herschrijven** (amend voor de laatste commit, interactieve rebase voor squashing/rewording/reordering, rebase voor lineaire geschiedenis, reset, filter-repo voor grootschalige wijzigingen) en dat ze allemaal **commit hashes veranderen** (nieuwe commits creëren) is de basis. Most kritisch is het begrijpen van de **gouden regel — nooit gedeelde/gepushte geschiedenis herschrijven** — essentieel omdat het herschrijven hashes verandert, waardoor je geschiedenis divergeert van die van medewerkers (die nog steeds de oude commits hebben), wat leidt tot duplicaten, conflicten en pijnlijke verzoening; het herschrijven van gedeelde geschiedenis is een ernstige verstoring die deze regel voorkomt, met **revert** (een veilige nieuw undocommit) als de juiste aanpak voor gedeelde branches. Het begrijpen van de **legitieme lokale toepassingen** (opschonen van WIP-commits voordat een PR, aanpassen van fouten voordat ze worden gepusht, rebasing om lineair te blijven voordat je deelt — allemaal op lokale, niet-gepushte commits) verduidelijkt wanneer herschrijven geschikt en waardevol is. Een cruciaal veiligheidsnuance: als een **geheim werd gecommit en gepusht**, is het herschrijven van geschiedenis om het te verwijderen onvoldoende — het geheim is al blootgesteld en moet **geroteerd** worden (een belangrijk real-world veiligheidspunt). Weten hoe je met de **zeldzame noodzakelijke herschrijving van gedeelde geschiedenis** omgaat (teamcoördinatie, `--force-with-lease` in plaats van `--force`, iedereen re-synct) weerspiegelt volwassen oordeel. Omdat geschiedenis herschrijven krachtig is maar ernstige problemen veroorzaakt wanneer het verkeerd wordt gebruikt op gedeelde geschiedenis, en omdat het begrijpen van de gouden regel, legitieme toepassingen en veilige praktijken essentieel is om het verantwoordelijk te gebruiken, is het begrijpen van wanneer en hoe je Git-geschiedenis moet herschrijven belangrijk kennis op senior-niveau — een onderwerp waarbij het begrijpen van de veiligheidsregels (vooral nooit gedeelde geschiedenis herschrijven) echte samenwerkingsrampen voorkomt en het oordeel weerspiegelt dat voor senior rollen bij Git in teams wordt verwacht.