# Wijzigingen in Claude Code ongedaan maken: /rewind en git > Terugdraaistanden, beperkingen van checkpoints, git checkout, stash, reflog en bescherming tegen destructieve opdrachten. Vijf manieren om een eerdere staat te herstellen. Source: https://ailoot.ai/blog/nl/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/nl/claude-code-undo-changes/ Language: nl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-6467fcf382f83772dc103320eda0e395c119d74412a8e622a784f65e04cfff68 [Praktische informatie over werken met Ailoot vind je in de documentatie](https://ailoot.ai/docs/). ## Wat is ongedaan maken in Claude Code, en waarom zijn drie niveaus niet genoeg?
Belangrijkste punten Ongedaan maken in Claude Code heeft drie niveaus: de ingebouwde opdracht `/rewind` (direct herstel binnen een sessie), `git checkout` (herstel naar de laatste commit) en `git reflog` (een noodvangnet als iemand `git reset --hard` heeft uitgevoerd). Elk niveau dekt een eigen soort fouten en niets buiten zijn grenzen. Alleen `/rewind` kennen betekent dat je bij de eerste serieuze blunder met lege handen staat.
Ik schakelde `/rewind` in mijn eerste week met Claude Code in, toen het de authenticatielogica van mijn project in twee prompts kapotmaakte. Ik draaide terug, haalde opgelucht adem en ging verder. Een maand later gebeurde er iets anders: ik schreef een schemamigratie, Claude hielp, ik committe, wisselde van branch — en besefte toen dat ik een noodzakelijke stap was vergeten. `/rewind` hielp niet; de sessie was inmiddels veranderd. `git checkout` naar de vorige commit hielp wel. Een maand later zei ik per ongeluk tegen de agent: “zet alles terug naar de laatste push”, waarna die `git reset --hard` uitvoerde en drie uur werk om zeep hielp. `git reflog` redde me: de hashes van de vernietigde commits stonden er nog. Die drie verhalen laten drie beschermingsniveaus zien die verschillend werken, andere fouten opvangen en allemaal nodig zijn. Deze gids legt elk niveau uit met opdrachten, beperkingen en voorbeelden, en laat ook zien hoe je een project vooraf configureert zodat Claude het niet meteen de eerste keer om zeep helpt. **3 niveaus van ongedaan maken — wat en wanneer:** | Niveau | Opdracht | Dekt | Dekt NIET | |----|----|----|----| | 1\. Binnen een sessie | `/rewind` of `Esc Esc` | Bestanden die Claude met zijn eigen tools heeft gewijzigd; gesprekshistorie | Bash-opdrachten, externe editors, databasemigraties | | 2\. Voor een commit | `git checkout .` of `git stash` | Alle niet-gecommitte wijzigingen in bestanden | Gecommitte commits | | 3\. Noodsituatie | `git reflog` + `git reset --hard ` | Commits vernietigd door `reset --hard` of force-push | Destructieve bash-opdrachten (rm, databasemigraties) | Hierna lopen we elk niveau langs: wat je precies moet doen, de valkuilen en hoe je alles zo configureert dat er niets ongedaan hoeft te worden gemaakt omdat er niets misgaat. ## Hoe roep je /rewind op: met de opdracht of met Esc-Esc?
Belangrijkste punten Er zijn twee manieren om het Rewind-menu in Claude Code te openen. De eerste is `/rewind` typen in het invoerveld. De tweede is twee keer op `Esc` drukken wanneer het invoerveld leeg is. Staat er tekst in het veld, dan wist dubbel Esc die eerst en slaat de inhoud op in de invoergeschiedenis; nogmaals dubbel drukken opent het menu. De opdracht `/rewind` heeft `/checkpoint` als alias.
Na elk antwoord maakt Claude automatisch een momentopname van alle bestanden die het in die sessie heeft bewerkt. Momentopnamen worden opgeslagen in `~/.claude/file-history/{sessionId}/` en maximaal 30 dagen bewaard. De momentopnamen zijn incrementeel: alleen de verschillen tussen toestanden worden opgeslagen, niet het hele bestand. Standaard worden er maximaal 100 momentopnamen per sessie bewaard. Dat betekent dat je in de meeste echte projecten op elk moment een volledige geschiedenis hebt van alle wijzigingen die Claude gedurende de werkdag heeft aangebracht. Druk twee keer op `Esc` wanneer het invoerveld leeg is om het rewind-menu te openen: ``` [user-input is empty] > _ [press Esc, Esc] Rewind to which message? 1. Create a migration for the User table (3 files changed) 2. Add the lastLoginAt field (1 file changed) 3. Rewrite the authorization logic (5 files changed) ... ``` Staat er tekst in het invoerveld, dan wist de eerste dubbele druk op `Esc` die tekst en slaat die op in de `Up`-geschiedenis. Dat is handig als je al bent begonnen met typen en beseft dat je moet terugdraaien. Een citaat uit de officiële documentatie van Anthropic:

Als er tekst in het promptveld staat, wist dubbel Esc die eerst in plaats van het menu te openen. De gewiste tekst wordt opgeslagen in de invoergeschiedenis, zodat je die na het rewind-menu met de pijl omhoog kunt herstellen.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
De opdracht `/rewind` doet hetzelfde: die opent het menu. Er is een alias, `/checkpoint`, die naar dezelfde plek leidt. Welke methode handiger is, hangt af van je gewoonte. Ik gebruik `Esc Esc`: dat is sneller en ik hoef mijn handen niet van het toetsenbord te halen. ## 6 modi in het Rewind-menu: welke kies je en wanneer?
Belangrijkste punten Nadat je een terugkeerpunt in het Rewind-menu hebt geselecteerd, verschijnt er een tweede menu met zes modi. Drie herstellen een toestand (`Restore code and conversation`, `Restore conversation`, `Restore code`), twee comprimeren de geschiedenis (`Summarize from here`, `Summarize up to here`) en één annuleert de actie (`Never mind`). Het meest voorkomende scenario — “zowel code als gesprek terugdraaien” — is de eerste optie.
Selecteer een punt in de lijst en je komt in het actiemenu. Zes opties, elk met een andere werking. **Volledige tabel met modi:** | Modus | Wat doet deze? | Wanneer kies je deze? | |----|----|----| | `Restore code and conversation` | Herstelt zowel bestanden als gesprekshistorie naar het geselecteerde punt | Het meest voorkomende scenario: Claude sloeg de verkeerde richting in en ik wil opnieuw beginnen met de juiste formulering | | `Restore conversation` | Draait alleen de gesprekshistorie terug; bestanden blijven zoals ze nu zijn | De code is goed, maar het gesprek ontspoorde; ik formuleer het vanaf dit punt opnieuw en behoud de huidige wijzigingen | | `Restore code` | Draait bestanden terug; het gesprek blijft zoals het is | Sommige wijzigingen van Claude waren onnodig, maar ik heb de context van het gesprek nog nodig (bijvoorbeeld omdat we vervolgstappen hebben afgesproken) | | `Summarize from here` | Comprimeert alles NA het geselecteerde punt tot een samenvatting. Raakt bestanden niet aan | Een lange debug-sessie heeft de context opgebruikt; ik moet ruimte vrijmaken en de oorspronkelijke instructies volledig behouden | | `Summarize up to here` | Comprimeert alles VOOR het geselecteerde punt tot een samenvatting. Raakt bestanden niet aan | Er was een lange briefing gevolgd door een specifieke taak; we comprimeren de briefing tot één bericht en laten het recente werk ongemoeid | | `Never mind` | Sluit het menu zonder wijzigingen | Ik ben van gedachten veranderd | De functie `Summarize up to here` verscheen in Claude Code v2.1.139-v2.1.142, uitgebracht op 11–15 mei 2026, in week 20:

Je kunt vroege context comprimeren via het Rewind-menu met ‘Summarize up to here’.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
Het verschil tussen `Restore` en `Summarize` is fundamenteel. Restore brengt je terug naar een eerdere toestand en maakt alles ongedaan wat na het geselecteerde punt is gebeurd. Summarize maakt niets ongedaan; het comprimeert alleen: de oorspronkelijke berichten blijven ter referentie in het sessietranscript staan, maar alleen de samenvatting blijft in de actieve context. Gebruik restore als je wilt dat het “is alsof dit nooit is gebeurd”. Gebruik summarize als je het wilt “bewaren zonder context in beslag te nemen”. Na `Restore conversation` of `Summarize from here` keert de oorspronkelijke tekst van de geselecteerde prompt terug naar het invoerveld; je kunt die bewerken en opnieuw versturen. Na `Summarize up to here` is het invoerveld leeg en blijf je aan het einde van het gesprek. ## Welke wijzigingen maakt /rewind NIET ongedaan?
Belangrijkste punten `/rewind` houdt alleen wijzigingen bij die Claude via zijn eigen tools voor het bewerken van bestanden heeft gemaakt. Het kan niets anders zien of herstellen. Er zijn drie soorten onzichtbare wijzigingen: bash-opdrachten (rm, mv, cp), externe bewerkingen (handmatige wijzigingen in een IDE, wijzigingen uit andere sessies) en handelingen buiten bestanden (databasemigraties, git push, externe API-aanroepen).
Dit is de belangrijkste beperking waar mensen tegenaan lopen: `/rewind` toont een groen vinkje en zegt “rewind geslaagd”, maar het project is nog steeds stuk omdat Claude meer heeft aangepast dan alleen bestanden. Laten we de drie gevallen bekijken. **1. Bash-opdrachten worden niet bijgehouden.** Als Claude in een beurt `rm file.txt` of `mv old.txt new.txt` uitvoert, worden die wijzigingen niet opgenomen in het checkpoint. De documentatie van Anthropic zegt dit uitdrukkelijk:

Checkpointing houdt geen bestanden bij die via bash-opdrachten zijn gewijzigd. Als Claude Code bijvoorbeeld rm file.txt, mv old.txt new.txt of cp source.txt dest.txt uitvoert, kunnen deze bestandswijzigingen niet via rewind ongedaan worden gemaakt.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Dat betekent dat `/rewind` niet alles herstelt als Claude zelf een bestand verwijdert, verplaatst of kopieert met de bash-tool. `git checkout` of herstellen vanaf een back-up kan helpen, maar daarvoor is meer nodig dan twee toetsen indrukken. **2. Externe bewerkingen worden niet opgevangen.** Als je handmatig een bestand opent in VS Code en iets bewerkt, of een tweede Claude-sessie dezelfde bestanden parallel wijzigt, kan de eerste sessie die wijzigingen niet zien. Een checkpointmomentopname wordt gemaakt wanneer Claude een beurt in de huidige sessie afrondt. Wat er tussen beurten gebeurt, valt buiten zijn verantwoordelijkheid. **3. Handelingen buiten bestanden vallen er helemaal buiten.** Een Prisma-migratie die via `npx prisma migrate dev` is toegepast, heeft het databaseschema gewijzigd; `/rewind` maakt dat niet ongedaan omdat de database buiten het bestandssysteem van het project staat. Een force-push naar `origin/main` is hetzelfde: de commit is naar de externe server gegaan en het checkpoint brengt die niet terug. Een externe API-aanroep die geld heeft afgeschreven of een record heeft verwijderd, kan alleen met de eigen mechanismen van de API ongedaan worden gemaakt. **Regel:** Als een taak iets buiten de projectbestanden beïnvloedt — databasemigraties, git push, externe API's — bereid dan voor elk extern effect een afzonderlijke terugdraaistrategie voor. `/rewind` is alleen de lokale bestandsgeschiedenis binnen de huidige sessie. ## /rewind versus git: wat is het verschil en waarom heb je beide nodig?
Belangrijkste punten `/rewind` is lokaal terugdraaien binnen één Claude Code-sessie. Het bewaart incrementele momentopnamen tot 30 dagen, maximaal 100 per sessie. git is de langetermijngeschiedenis van het project, gedeeld met het team, met branches, mergeconflicten en een externe repository. Het een vervangt het ander niet. De beste werkwijze is bij elke logische mijlpaal een `git commit` te maken en tussen commits op `/rewind` te vertrouwen.
De documentatie van Anthropic beschrijft deze combinatie rechtstreeks:

Checkpoints zijn ontworpen voor snel herstel op sessieniveau. Blijf voor commits, branches en langetermijngeschiedenis een versiebeheersysteem gebruiken (bijvoorbeeld Git). Checkpoints vullen normaal versiebeheer aan, maar vervangen het niet. Zie checkpoints als ‘lokaal ongedaan maken’ en Git als ‘permanente geschiedenis’.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
De verschillen in één tabel: | Parameter | /rewind | git | |----|----|----| | Detailniveau | Elke beurt in het gesprek | Elke commit | | Opslag | Tot 30 dagen, maximaal 100 per sessie, lokaal in `~/.claude/file-history/` | Permanent, in de `.git/` van de repository en op de externe server | | Wat het bijhoudt | Claude's bewerkingen via de eigen tools | Alle gecommitte wijzigingen | | Wat het NIET bijhoudt | Bash, externe bewerkingen, migraties, push | Niet-gecommitte wijzigingen | | Opdracht | Een opdracht binnen Claude | Een extern versiebeheersysteem | | Draait het gesprek terug | Ja | Nee | | Werkt over sessies heen | Alleen binnen dezelfde sessie | Overal | De combinatie is eenvoudig: zodra je een toestand bereikt waarin “dit werkt en ik wil het niet kwijtraken”, maak je een `git commit`. Vertrouw tussen commits op `/rewind`: dat gaat direct, vereist geen commitbericht en vervuilt de git-geschiedenis niet met tussenstappen. Commit wanneer het werk klaar is, bij voorkeur met een betekenisvolle, ondeelbare commit. ## Waarom dekt één /rewind niet de hele taak? Ongedaan maken is één onderdeel van **context engineering**. Beheer de sessiecontext (wanneer je commit, wanneer je `/rewind` gebruikt en welke regels je in `CLAUDE.md` zet) en je krijgt een voorspelbare Claude die het project niet vernietigt of werk kwijtraakt. ## Waarom is `git reset --hard` gevaarlijk als je Claude vraagt om “terug te gaan”?
Belangrijkste punten In gewone taal betekent “teruggaan” “de geschiedenis bekijken”, niet “die vernietigen”; Claude zou standaard `git checkout` moeten voorstellen, niet `reset --hard`; bescherming configureer je in CLAUDE.md.
Een verzoek om “de huidige toestand op te slaan en terug te gaan naar de laatste push” kan tot deze opdrachten leiden: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # niet-gecommitte wijzigingen opgeslagen git reset --hard 35eb731 # commits d63695e..882e618 vernietigd ``` De eerste opdracht was correct: die sloeg de niet-gecommitte wijzigingen op in de stash. De tweede was destructief: die herschreef de branch naar commit `35eb731`, waardoor alle commits tussen die commit en `882e618` verweesd raakten. Standaard blijven verweesde commits in `.git/objects/` staan totdat `git gc` wordt uitgevoerd, meestal automatisch binnen twee weken. Maar als je op dat moment niet wist wat je moest doen, werkte de tijd al tegen je. De logica is eenvoudig: in gewone taal betekenen “teruggaan”, “terugkeren”, “herstellen”, “terugdraaien” en “ongedaan maken” dat je “terugkijkt” of “naar een veilige plek terugkeert”. Ze betekenen niet “de geschiedenis vernietigen”. De opdracht `git reset --hard` vernietigt die: hij herschrijft de branch en verwijdert commits uit de reeks die via HEAD bereikbaar is. Een veilig alternatief is `git checkout `, dat een detached HEAD maakt en je de oude toestand laat bekijken zonder branches aan te raken. De belangrijkste praktische les is om de huidige toestand met `git commit` vast te leggen voordat je aan een omvangrijke taak begint, vooral vóór het refactoren van meerdere bestanden. Eén commit maakt van elke blunder van Claude één `git checkout .`-opdracht, zonder werk te verliezen. ## Hoe redt git reflog je na een destructieve reset?
Belangrijkste punten `git reflog` toont de lokale geschiedenis van alle HEAD-verplaatsingen in de repository, zelfs commits die door `git reset --hard` of force-push zijn verwijderd. Elke verplaatsing wordt standaard 90 dagen bewaard. Als Claude (of jij, of iemand anders) commits met een destructieve opdracht heeft vernietigd, toont `git reflog` hun hashes en kun je de branch herstellen met `git reset --hard `.
Voer na een destructieve reset meteen `git reflog` uit: ```bash git reflog ``` De uitvoer ziet er zo uit: ``` 35eb731 HEAD@{0}: reset: moving to 35eb731 882e618 HEAD@{1}: commit: middleware refactoring complete d63695e HEAD@{2}: commit: leaveRemove method finalized 1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled 35eb731 HEAD@{4}: pull origin main ``` `HEAD@{1}` tot en met `HEAD@{3}` zijn precies die “vernietigde” commits. Ze zijn niet verdwenen uit de lokale objectopslag van git; ze zijn alleen niet meer bereikbaar via de branch. Zo herstel je ze: ```bash # Maak een branch vanaf de laatste “vernietigde” commit git branch recovered-work 882e618 # Of schakel er direct naartoe git reset --hard 882e618 ``` Daarna bevat de branch weer de volledige geschiedenis tot aan de ramp. **Beperkingen van reflog:** 1. **Alleen lokaal.** De reflog staat in `.git/logs/HEAD`; hij staat niet in de externe repository. Als je een force-push uitvoert en daarna je lokale repositorykopie verwijdert, verdwijnt de reflog met de map. 2. **Standaard 90 dagen.** Oudere vermeldingen kunnen door git gc worden verwijderd. Je kunt dit configureren met `git config gc.reflogExpire 200.days.ago`. 3. **Dekt niet wat nooit in HEAD stond.** Als een commit alleen in de stash stond en de stash werd vernietigd, toont de reflog alleen de laatste toestand van de stash, niet de interne geschiedenis ervan. **Regel voor het team:** voer vlak na een ramp nooit `git gc --aggressive` uit. Onderzoek eerst de situatie met reflog en herstel de gegevens; doe de rest daarna. Verwijder ook nooit de lokale repositorykloon voordat je zeker weet dat alles wat je nodig hebt is gepusht. ## Hoe bescherm je een project met CLAUDE.md tegen destructieve git-opdrachten?
Belangrijkste punten Voeg in `CLAUDE.md` van je project een instructieblok toe met daarin welke git-opdrachten Claude zelfstandig mag uitvoeren, waarvoor uitdrukkelijke bevestiging nodig is en wat verboden is zonder een exacte formulering van de gebruiker. Claude behandelt CLAUDE.md als de systeemprompt van het project en volgt deze regels standaard. Zo verandert één “gevaarlijke” prompt in twee veilige opdrachten.
De kwetsbaarheid is dat Claude standaard geen beschermende context heeft. Het interpreteert “teruggaan” als `git reset --hard`, omdat dat technisch gezien een geldige methode is. Zet de bescherming in `CLAUDE.md`, het systeempromptbestand van het project. **Minimale regel** (voeg toe aan je `CLAUDE.md`): ```markdown ## Git-veiligheidsprotocol - Voer NOOIT destructieve git-opdrachten uit (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), tenzij ik uitdrukkelijk om deze handelingen vraag. Ongeoorloofde destructieve handelingen helpen niet en kunnen werkverlies veroorzaken. - Wanneer ik “teruggaan”, “terugkeren”, “herstellen”, “terugdraaien” of “ongedaan maken” zeg, interpreteer dat dan als opdrachten om de situatie te BEKIJKEN: gebruik `git log`, `git diff`, `git checkout ` (maakt een detached HEAD) of `git stash` (bewaart wijzigingen). - Vraag ALTIJD om bevestiging vóór ELKE opdracht die: - De positie van HEAD naar een andere commit op een branch verplaatst - De commitgeschiedenis wijzigt - Niet-gecommitte wijzigingen kan verliezen - De vlaggen --hard, --force of --aggressive bevat - Geef vóór elke destructieve opdracht een genummerde vergelijking: - VEILIG: gebruik `git checkout ` om tijdelijk te kijken - DESTRUCTIEF: gebruik `git reset --hard` om iets permanent te vernietigen - Wacht op mijn uitdrukkelijke keuze voordat je de opdracht uitvoert. ``` **Uitgebreide regel** voor het team (voeg toe aan `CLAUDE.md` in de hoofdmap van de repository): ```markdown ## Git-werkwflowregels - Maak bij elke werkende mijlpaal een commit. Voer vóór een WIP-commit `git status` en `git diff` uit, stage alleen expliciet beoordeelde bestanden op naam met `git add -- path/to/file` en bekijk daarna de staged diff voordat je commit. Een timer herinnert aan beoordeling en geeft geen toestemming om de hele werkboom te stagen. - Gebruik voor commits van Claude nooit `git add .` of `git add -A`. Specificeer alleen bestanden op naam, na `git status` + `git diff`. - Stop en vraag het voordat je `git push --force` naar main uitvoert. Force-push in featurebranches alleen voorzichtig en als je zeker weet dat ik bereid ben de vorige versie te verliezen. - Kies bij het oplossen van mergeconflicten niet meteen “ours” of “theirs”; laat me eerst beide versies zien, dan beslis ik. - `.gitignore` moet `.env*`, `.claude/personal/`, `node_modules/` en `dist/` bevatten. Ontbreken ze, voeg ze dan toe. ``` Nadat je deze blokken hebt toegevoegd, zou de volgende opdracht “teruggaan naar de laatste push” tot dit antwoord leiden: > Ik zie 3 niet-gecommitte bestanden en 4 commits vóór de laatste push. Er zijn twee opties: > > 1. VEILIG: maak met `git checkout ` een `view-last-push`-branch aan; ik bewaar al het werk, maar toon tijdelijk de toestand van de push. > 2. DESTRUCTIEF: `git reset --hard `; ik vernietig 4 commits en de niet-gecommitte wijzigingen permanent. Ze kunnen alleen binnen 90 dagen via `git reflog` worden hersteld. Welke optie kies je? Dat is een gesprek van een halve minuut in plaats van vier uur verloren werk. ## Wat zijn de 5 manieren om iets in Claude Code ongedaan te maken, en hoe kies je de juiste?
Belangrijkste punten Als er iets misgaat, zijn er vijf niveaus van wanhoop: `/rewind` (binnen een sessie), `git checkout .` (niet-gecommitte wijzigingen), `git checkout ` (terug naar een oude commit zonder geschiedenis te verliezen), `git reset --hard ` (de branch terugzetten en commits ervoor verliezen), `git reflog` + herstel (ramp, alles is weg). Elk niveau is zwaarder en gevaarlijker dan het vorige.
Het scenario “Claude heeft het kapotgemaakt, ik moet het dringend herstellen” volg je van onderaf op deze ladder. Begin altijd op niveau 1. **Niveau 1. `/rewind` — direct ongedaan maken binnen een sessie.** Druk op `Esc Esc` of typ `/rewind`. Kies het punt van vóór de fout. Kies een modus (meestal `Restore code and conversation`). Een seconde later ben je terug in het verleden en kun je opnieuw beginnen. Dekt 80% van de gevallen waarin “Claude iets verkeerds heeft gedaan”. **Niveau 2. `git checkout .` — alle niet-gecommitte wijzigingen ongedaan maken.** ```bash git diff # bekijk eerst wat er daadwerkelijk is gewijzigd git checkout . # maak alle niet-gecommitte wijzigingen in alle bestanden ongedaan # of selectief: git checkout -- path/to/file.ts # slechts één bestand ``` Handig als `/rewind` niet werkte (bijvoorbeeld omdat Claude bestanden via bash heeft aangepast) of als je wijzigingen buiten de sessiegeschiedenis ongedaan moet maken. Alle niet-gecommitte wijzigingen verdwijnen permanent. Als je daar mogelijk spijt van krijgt, voer dan eerst `git stash` uit (zie niveau 2.5). **Niveau 2.5. `git stash` — zet je wijzigingen op de plank.** ```bash git stash save "might still need this" # keer terug naar een schone toestand (zonder wijzigingen) # ... # van gedachten veranderd? Herstel vanuit de stash: git stash pop ``` Een goed compromis tussen “voor altijd verliezen” en “laten zoals het is”. De stash blijft lokaal totdat je die uitdrukkelijk wist. **Niveau 3. `git checkout ` — terug naar een oude commit zonder geschiedenis te verliezen.** ```bash git log --oneline # vind de hash van de juiste commit, bijvoorbeeld abc1234 git checkout abc1234 # detached HEAD — bekijken zonder iets te wijzigen # bevalt de toestand? Maak er een branch van: git checkout -b recovery abc1234 # terugkeren: git checkout main ``` Dit is een veilige “tijdelijke terugkeer”. Een detached HEAD wijzigt de branch niet; je huidige werk in `main` (of de branch waarop je zat) blijft intact. Als je in deze toestand wilt werken, maak dan een branch aan. **Niveau 4. `git reset --hard ` — verplaats de branch terug naar een punt.** ⚠️ Destructief. Commits na de opgegeven hash raken verweesd. ```bash git reflog # noteer de hash van de huidige toestand git reset --hard abc1234 # herschrijf de branch # een fout ontdekt? Keer terug via reflog: git reset --hard HEAD@{1} # terug naar de toestand van vóór de reset ``` Gebruik dit alleen als je zeker weet dat je de commits ervoor niet nodig hebt. Controleer altijd `git reflog` VÓÓR de reset, zodat je weet waar je naartoe kunt terugkeren als je van gedachten verandert. **Niveau 5. `git reflog` + herstel — een rampscenario.** Iemand (Claude, jij of een collega) heeft al `git reset --hard` of force-push uitgevoerd en het werk gewist. Wat doe je? ```bash git reflog # zoek de laatste hash van vóór de ramp git branch recovered HEAD@{N} # maak daar een branch van git checkout recovered # schakel ernaar over git diff main # vergelijk met de huidige toestand git checkout main && git merge recovered # herstel naar main als je het zeker weet ``` Als de reflog al is gewist (standaard na 90 dagen), is het laatste redmiddel `git fsck --lost-found`, dat dangling commits in `.git/objects/` laat zien. Dit is bijna archeologie, maar soms werkt het. **Regel voor het kiezen van een niveau:** | Wat is er gebeurd | Niveau | |-----------------------------------------------|-----------------------------| | Claude heeft 3 bestanden op de verkeerde manier herschreven | 1\. `/rewind` | | Ik heb het geprobeerd, het beviel niet en de sessie helpt niet | 2\. `git checkout .` | | Ik heb het handmatig kapotgemaakt, wil het niet verliezen en herstel het misschien | 2.5. `git stash` | | Ik heb gecommit; ik moet één commit terug | 3\. `git checkout ` | | Ik weet zeker dat ik de commits ervoor niet nodig heb | 4\. `git reset --hard` | | Ik heb het al gewist met een destructieve opdracht | 5\. `git reflog` | ## Hoe bescherm je een project zodat er niets ongedaan hoeft te worden gemaakt?
Belangrijkste punten De beste manier om iets ongedaan te maken is ervoor zorgen dat het niet nodig is. Drie beschermingsregels: beoordeel elke 30 minuten de voortgang en commit een werkende mijlpaal door uitsluitend beoordeelde paden expliciet te stagen; zet de vereiste regels `.claude/personal/` en `.env*` in `.gitignore`; voer grote experimenten uit op een aparte branch met `git checkout -b experiment-`. Dit verkleint het herstelgat voor gecommitte bestanden; externe systemen en ongecommit werk hebben nog steeds een eigen herstelplan nodig.
**Regel 1. Commit elke 30 minuten.** Wacht niet tot “de taak af is”. Commit elke tussenstap die werkt. Commitberichten mogen van alles zijn; het belangrijkste is dat Claude (of jij) met één `git checkout`-opdracht naar een werkende toestand kan terugkeren. ```bash # aan het begin van een taak git status # bekijk alle staged en unstaged paden git diff # beoordeel de wijzigingen # Vervang dit voorbeeldpad door het echte bestand dat je hebt beoordeeld. git add -- path/to/file.ts git diff --cached # controleer precies wat wordt gecommit git commit -m "wip: starting User schema migration" # na 30 minuten (of na de eerste werkende iteratie) git status git diff git add -- path/to/file.ts # echt beoordeeld pad, geen directorywildcard git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # aan het einde van de taak — een betekenisvolle commit git reset --soft HEAD~2 # voeg de drie wip-commits samen tot één git commit -m "feat(auth): add lastLoginAt field to User table" ``` Voeg je een PostToolUse-herinnering toe, behoud dan dezelfde regel voor beoordeling en expliciete paden bij het stagen. Maak van een timer geen ongecontroleerde autocommit: anders kunnen ongerelateerde bewerkingen of al gestagede bestanden in de commit terechtkomen. **Regel 2. Minimale `.gitignore`.** Deze regels zijn vereist in de hoofdmap van het project: ```gitignore # geheimen .env .env.local .env.*.local # lokale Claude Code-instellingen (niet naar de teamrepository pushen) .claude/personal/ .claude/sessions/ .claude/file-history/ # afhankelijkheden en build node_modules/ dist/ .next/ build/ ``` Ik bewaar de map `.claude/personal/` voor mijn eigen experimenten en notities; die mag niet in de gedeelde repository terechtkomen. De mappen `.claude/sessions/` en `.claude/file-history/` zijn de lokale opslag van Claude Code; ze horen niet in de repository, nemen veel ruimte in en zijn gekoppeld aan een specifieke machine. **Regel 3. Experimenteer op een aparte branch.** Is de taak groot (10+ bestanden refactoren, overstappen op een nieuwe database, een module herschrijven), doe het dan niet op de main-branch: ```bash git checkout -b experiment/auth-rewrite # werk en commit elke 30 minuten # als het werkt: git checkout main git merge experiment/auth-rewrite # als het niet werkt: git checkout main git branch -D experiment/auth-rewrite # verwijder de branch # klaar, de main-branch is intact ``` Deze eenvoudige gewoonte verandert “Claude heeft het project vernield” in “Claude heeft één branch vernield, ik heb die verwijderd en we beginnen opnieuw”. **Regel 4. Gebruik vóór gevaarlijke handelingen `git tag`.** Maak vóór een databasemigratie, grote refactor of afhankelijkheidsupdate een tag aan: ```bash git tag pre-prisma-migration-v2 # werk # gaat er iets mis: git reset --hard pre-prisma-migration-v2 # of kijk alleen even: git checkout pre-prisma-migration-v2 ``` Een tag is een benoemde verwijzing naar een commit die je zelfs na het opschonen van de reflog niet kwijtraakt. ## Wat nu: hoe past ongedaan maken in context engineering?
Belangrijkste punten Ongedaan maken is geen afzonderlijke vaardigheid, maar onderdeel van het beheren van de sessiecontext in Claude Code. Als je weet wanneer je op `/rewind` drukt, wanneer je `git commit` uitvoert en wanneer je `git stash` gebruikt, beheer je een hele workflow en niet één opdracht. Dit valt onder **Context Engineering**. Zonder dit gedraagt Claude zich als een gewone assistent; ermee als een voorspelbaar hulpmiddel.
Deze drie niveaus van ongedaan maken vormen de infrastructuur voor één vaardigheid: weten hoe je een toestand herstelt wanneer er iets stukgaat. Op zichzelf is die vaardigheid beperkt. Maar in combinatie met andere tools voor context engineering wordt het iets meer. Plan Mode laat je niet meteen code schrijven: eerst komt het plan, dan de bevestiging en daarna de uitvoering. Dit is preventief ongedaan maken: je schrijft niets wat je later moet terugdraaien, omdat het plan vooraf is beoordeeld. Lees meer in de gids over [Plan Mode in Claude Code](https://ailoot.ai/blog/nl/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/nl/claude-md-template/) bevat regels die Claude standaard respecteert, waaronder het hierboven besproken Git-veiligheidsprotocol. Dit is preventieve bescherming tegen destructieve opdrachten. Het [Second Brain](https://ailoot.ai/blog/nl/tweede-brein-claude-code/) geeft Claude tussen sessies door geheugen over het project: het weet welke code je hebt, wat de bedrijfslogica is en welke afspraken eerder zijn gemaakt. Hoe meer geheugen, hoe kleiner de kans dat het iets verkeerd doet. [Skills en subagents](https://ailoot.ai/blog/nl/claude-code-skills-library/) zijn je methodologie in code. Als de juiste git-workflow in een Skill is ingebouwd, voert geen enkele subagent `git reset --hard` uit zonder bevestiging. En dit alles samen is **Context Engineering**. Beheer de context vóór de prompt, niet tijdens het uitvoeren ervan. Lees meer over [wat context engineering is](https://ailoot.ai/blog/nl/context-engineering/). Ongedaan maken is de laatste verdedigingslinie. Plan Mode + CLAUDE.md + Second Brain + Skills zijn de eerste vier. Als die zijn ingesteld, hoef je zelden iets ongedaan te maken en gaat dat snel. Zijn ze niet ingesteld, dan wordt het een dagelijks ritueel.
### Bronnen - [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new) - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
Ongedaan maken begint waar plannen eindigt. [Ailoot openen](https://ailoot.ai/). ## Vragen en antwoorden ### Gebruik ik git add . voor een WIP-checkpoint? Nee. Voer git status en git diff uit, stage alleen de bestanden op naam die je hebt beoordeeld en bekijk daarna git diff --cached voordat je commit. Een periodiek checkpoint geeft geen toestemming om ongerelateerde of eerder gestagede wijzigingen mee te nemen. ### Kan /rewind een databasemigratie of externe API-actie terugdraaien? Nee. De gids beperkt checkpoints tot ondersteunde bestandsbewerkingen in de sessie. Database-effecten, externe Git-acties en API-effecten vereisen aparte herstelstappen; gebruik Git of een back-up voor bestanden buiten het bereik van het checkpoint. ## Ailoot · Het bedrijf en zijn projectenportefeuille Ailoot bouwt op opgebouwde operationele ervaring, een groot klantenbestand, een stabiele dienst en doorlopende KPI-controle. Het bedrijf en zijn projectenportefeuille: miljoenen klanten; maandelijkse verkopen in de miljarden. Ailoot gebruikt die operationele ervaring voor API-toegang tot AI-functies in klantproducten, agents, applicaties en automatiseringen.