# Sådan fortryder du ændringer i Claude Code: /rewind og git > Tilbageførselstilstande, begrænsninger ved kontrolpunkter, git checkout, stash, reflog og beskyttelse mod destruktive kommandoer. Fem måder at gendanne en tilstand på. Source: https://ailoot.ai/blog/da/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/da/claude-code-undo-changes/ Language: da Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-a248953666633c8a73267ce77a0d034fb105dfaacbc58633e61a0024365b96d1 [Praktiske oplysninger om at arbejde med Ailoot findes i dokumentationen](https://ailoot.ai/docs/). ## Hvad vil det sige at fortryde i Claude Code, og hvorfor er tre niveauer ikke nok?
Vigtige punkter Der er tre niveauer for at fortryde i Claude Code: den indbyggede kommando `/rewind` (øjeblikkelig gendannelse i en session), `git checkout` (gendannelse til den seneste commit) og `git reflog` (et katastrofeberedskab, hvis nogen har kørt `git reset --hard`). Hvert niveau dækker sin egen type fejl og intet ud over sine grænser. Hvis du kun kender `/rewind`, står du med bukserne nede ved den første alvorlige fejl.
Jeg slog `/rewind` til i min første uge med Claude Code, da det ødelagde projektets godkendelseslogik på to prompts. Jeg rullede tilbage, trak vejret lettet og fortsatte. En måned senere opstod en ny situation: Jeg skrev en skemamigrering, Claude hjalp, jeg lavede en commit og skiftede gren – og indså, at jeg havde glemt et nødvendigt trin. `/rewind` hjalp ikke – sessionen var allerede en anden. `git checkout` til den forrige commit hjalp. En måned efter det bad jeg ved en fejl agenten om at ”rulle alt tilbage til den seneste push”, og den kørte `git reset --hard`, hvilket ødelagde tre timers arbejde. `git reflog` reddede mig – hasherne for de ødelagte commits var der stadig. De tre historier handler om tre beskyttelsesniveauer, der fungerer forskelligt, fanger forskellige fejl og alle er nødvendige. Denne guide gennemgår hvert niveau med dets kommandoer, begrænsninger og eksempler og viser også, hvordan du konfigurerer et projekt på forhånd, så Claude ikke ødelægger det første gang. **3 niveauer for at fortryde – hvad og hvornår:** | Niveau | Kommando | Dækker | Dækker IKKE | |----|----|----|----| | 1\. I en session | `/rewind` eller `Esc Esc` | Filer ændret af Claude gennem dets egne værktøjer; samtalehistorik | Bash-kommandoer, eksterne editorer, databasemigreringer | | 2\. Før en commit | `git checkout .` eller `git stash` | Alle ikke-committede ændringer i filer | Committede ændringer | | 3\. Katastrofe | `git reflog` + `git reset --hard ` | Commits ødelagt af `reset --hard` eller force-push | Destruktive bash-kommandoer (rm, databasemigreringer) | Nu gennemgår vi hvert niveau – præcis hvad du skal gøre, faldgruberne, og hvordan du konfigurerer tingene, så der ikke er noget at fortryde, fordi intet gik galt. ## Hvordan åbner du /rewind: med kommandoen eller Esc-Esc?
Vigtige punkter Der er to måder at åbne tilbagerulningsmenuen i Claude Code på. Den første er at skrive `/rewind` i inputfeltet. Den anden er at trykke på `Esc` to gange, når inputfeltet er tomt. Hvis der er tekst i feltet, rydder et dobbelttryk først teksten og gemmer den i inputhistorikken; endnu et dobbelttryk åbner menuen. Kommandoen `/rewind` har aliaset `/checkpoint`.
Efter hvert svar tager Claude automatisk et øjebliksbillede af alle filer, det har redigeret i den session. Øjebliksbillederne gemmes i `~/.claude/file-history/{sessionId}/` og opbevares i op til 30 dage. De er inkrementelle – kun forskellene mellem tilstandene gemmes, ikke hele filen. Som standard gemmes op til 100 øjebliksbilleder pr. session. Det betyder, at du i de fleste virkelige projekter til enhver tid har en komplet historik over alle Claudes ændringer i løbet af arbejdsdagen. Åbn tilbagerulningsmenuen ved at trykke på `Esc` to gange, når inputfeltet er tomt: ``` [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) ... ``` Hvis der er tekst i inputfeltet, rydder det første dobbelttryk på `Esc` teksten og gemmer den i historikken, som du åbner med `Op`. Det er nyttigt, hvis du allerede er begyndt at skrive og indser, at du skal rulle tilbage. Et citat fra Anthropics officielle dokumentation:

Hvis der er tekst i promptfeltet, rydder et dobbelttryk på Esc først teksten i stedet for at åbne menuen. Den ryddede tekst gemmes i inputhistorikken, så du kan gendanne den med pil op efter tilbagerulningsmenuen.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Kommandoen `/rewind` gør det samme – den åbner menuen. Der findes et alias, `/checkpoint`, som fører til samme sted. Hvilken metode der er mest praktisk, afhænger af vane. Jeg bruger `Esc Esc` – det går hurtigere, og jeg behøver ikke flytte hænderne fra tastaturet. ## 6 tilstande i tilbagerulningsmenuen: hvilken skal du vælge, og hvornår?
Vigtige punkter Når du har valgt et tilbagerulningspunkt i menuen, vises en menu nummer to med seks tilstande. Tre gendanner tilstanden (`Restore code and conversation`, `Restore conversation`, `Restore code`), to komprimerer historikken (`Summarize from here`, `Summarize up to here`), og én annullerer handlingen (`Never mind`). Det mest almindelige scenarie – ”rul både kode og samtale tilbage” – er den første mulighed.
Vælg et punkt på listen, så kommer du til handlingsmenuen. Seks punkter, der hver gør noget forskelligt. **Komplet tabel over tilstandene:** | Tilstand | Hvad den gør | Hvornår du skal vælge den | |----|----|----| | `Restore code and conversation` | Gendanner både filer og samtalehistorik til det valgte punkt | Det mest almindelige scenarie: Claude gik i den forkerte retning, og jeg vil begynde forfra med en bedre formulering | | `Restore conversation` | Ruller kun samtalehistorikken tilbage; filerne forbliver, som de er nu | Koden er god, men samtalen kom på afveje; jeg omformulerer fra dette punkt og bevarer de aktuelle ændringer | | `Restore code` | Ruller filerne tilbage; samtalen forbliver, som den er | Nogle af Claudes ændringer var unødvendige, men jeg har stadig brug for samtalekonteksten (for eksempel fordi vi aftalte de næste trin) | | `Summarize from here` | Komprimerer alt EFTER det valgte punkt til et resumé. Rører ikke filer | En lang fejlfindingssession har brugt konteksten; jeg skal frigøre plads, mens de oprindelige instruktioner bevares fuldt ud | | `Summarize up to here` | Komprimerer alt FØR det valgte punkt til et resumé. Rører ikke filer | Der var en lang indledende briefing efterfulgt af en specifik opgave – vi komprimerer briefingen til én besked og lader det seneste arbejde være, som det er | | `Never mind` | Lukker menuen uden ændringer | Jeg har ombestemt mig | Funktionen `Summarize up to here` kom i Claude Code v2.1.139-v2.1.142, udgivet 11.–15. maj 2026, uge 20:

Du kan komprimere tidlig kontekst via tilbagerulningsmenuen med ”Summarize up to here”.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
Forskellen mellem `Restore` og `Summarize` er grundlæggende. Restore vender tilbage til en tidligere tilstand og fortryder alt, der skete efter det valgte punkt. Summarize fortryder ikke noget; det komprimerer kun – de oprindelige beskeder forbliver i sessionsudskriften som reference, men kun resuméet er tilbage i den aktive kontekst. Brug Restore, når du vil have det til at være ”som om det aldrig skete”. Brug Summarize, når du vil ”beholde det, men ikke bruge plads på det i konteksten”. Efter `Restore conversation` eller `Summarize from here` kommer den oprindelige tekst fra den valgte prompt tilbage i inputfeltet – du kan redigere den og sende den igen. Efter `Summarize up to here` er inputfeltet tomt, og du er stadig ved slutningen af samtalen. ## Hvilke ændringer fortryder /rewind IKKE?
Vigtige punkter `/rewind` holder kun styr på ændringer, Claude foretager gennem sine egne filredigeringsværktøjer. Det kan ikke se eller gendanne andet. Der er tre slags usynlige ændringer: bash-kommandoer (rm, mv, cp), eksterne redigeringer (dine manuelle ændringer i en IDE, ændringer fra andre sessioner) og handlinger uden for filer (databasemigreringer, git push, eksterne API-kald).
Dette er den største begrænsning, folk støder på: `/rewind` viser et grønt flueben og siger ”tilbagerulning lykkedes”, men projektet er stadig ødelagt, fordi Claude gjorde mere end blot at ændre filer. Lad os se på de tre tilfælde. **1. Bash-kommandoer spores ikke.** Hvis Claude kører `rm file.txt` eller `mv old.txt new.txt` i en tur, bliver ændringerne ikke medtaget i kontrolpunktet. Anthropics dokumentation siger udtrykkeligt:

Kontrolpunkter sporer ikke filer, der er ændret via bash-kommandoer. Hvis Claude Code for eksempel kører rm file.txt, mv old.txt new.txt eller cp source.txt dest.txt, kan disse filændringer ikke fortrydes med rewind.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Det betyder, at `/rewind` ikke gendanner alt, hvis Claude selv sletter, flytter eller kopierer en fil med bash-værktøjet. `git checkout` eller gendannelse fra en sikkerhedskopi kan hjælpe, men det kræver mere end to tastetryk. **2. Eksterne redigeringer opfanges ikke.** Hvis du manuelt åbner en fil i VS Code og redigerer noget, eller en anden Claude-session ændrer de samme filer parallelt, kan den første session ikke se ændringerne. Et kontrolpunkt tages, når Claude afslutter en tur i den aktuelle session. Det, der sker mellem turene, er uden for dens ansvar. **3. Handlinger uden for filer dækkes slet ikke.** En Prisma-migrering, der anvendes gennem `npx prisma migrate dev`, ændrede databaseskemaet – `/rewind` kan ikke fortryde den, fordi databasen ligger uden for projektets filsystem. En force-push til `origin/main` er det samme: commiten blev sendt til fjernserveren, og kontrolpunktet får den ikke tilbage. Et eksternt API-kald, der opkrævede penge eller slettede en post, kan kun fortrydes med API'ets egne mekanismer. **Regel:** Hvis en opgave påvirker noget uden for projektfilerne – databasemigreringer, git push eller eksterne API'er – skal du forberede en særskilt tilbagerulningsstrategi for hver ekstern effekt. `/rewind` er kun lokal filhistorik i den aktuelle session. ## /rewind sammenlignet med git: hvordan er de forskellige, og hvorfor skal du bruge begge?
Vigtige punkter `/rewind` er en lokal tilbagerulning i én enkelt Claude Code-session. Den gemmer inkrementelle øjebliksbilleder i op til 30 dage, op til 100 pr. session. git er langsigtet projekthistorik, delt med teamet, med grene, mergekonflikter og et fjernlager. Det ene erstatter ikke det andet. Den bedste praksis er at lave en `git commit` ved hver logisk milepæl og bruge `/rewind` mellem commits.
Anthropics dokumentation beskriver direkte, hvordan de to supplerer hinanden:

Kontrolpunkter er beregnet til hurtig gendannelse på sessionsniveau. Fortsæt med at bruge et versionsstyringssystem (for eksempel Git) til commits, grene og langsigtet historik. Kontrolpunkter supplerer almindelig versionsstyring, men erstatter den ikke. Tænk på kontrolpunkter som ”lokal fortrydelse” og Git som ”permanent historik”.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Forskellene i én tabel: | Parameter | /rewind | git | |----|----|----| | Granularitet | Hver tur i samtalen | Hver commit | | Lagring | Op til 30 dage, op til 100 pr. session, lokalt i `~/.claude/file-history/` | Permanent, i repoets `.git/` og på fjernserveren | | Hvad det sporer | Claudes ændringer gennem dets egne værktøjer | Alle committede ændringer | | Hvad det IKKE sporer | Bash, eksterne redigeringer, migreringer, push | Ikke-committede ændringer | | Kommando | En kommando i Claude | Et eksternt versionsstyringssystem | | Ruller samtalen tilbage | Ja | Nej | | Virker på tværs af sessioner | Kun i den samme session | Overalt | Sammenhængen er enkel: Når du når en tilstand, hvor ”det her virker, og jeg vil ikke miste det”, skal du lave en `git commit`. Mellem commits bruger du `/rewind` – det sker øjeblikkeligt, kræver ingen commitbesked og fylder ikke git-historikken med mellemtilstande. Når arbejdet er færdigt, laver du en commit, helst en meningsfuld og atomisk en. ## Hvorfor dækker én /rewind ikke hele opgaven? Fortrydelse er ét eksempel på **kontekstteknik**. Hvis du styrer sessionens kontekst (hvornår du skal lave en commit, hvornår du skal trykke på `/rewind`, hvilke regler du skal skrive i `CLAUDE.md`), får du en forudsigelig Claude, der ikke ødelægger projektet eller mister arbejde. ## Hvorfor er `git reset --hard` farlig, når du beder Claude om at ”rulle tilbage”?
Vigtige punkter På naturligt sprog betyder ”rul tilbage” ”se i historikken”, ikke ”ødelæg den”; Claude bør som standard foreslå `git checkout`, ikke `reset --hard`; beskyttelsen konfigureres i CLAUDE.md.
En anmodning om at ”gemme den aktuelle tilstand og rulle tilbage til den seneste push” kan føre til disse kommandoer: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` Den første kommando var korrekt – den gemte de ikke-committede ændringer i stash. Den anden var destruktiv: Den omskrev grenen til commiten `35eb731`, og alle commits mellem den og `882e618` blev forældreløse. Som standard bliver forældreløse commits i `.git/objects/`, indtil `git gc` køres, hvilket normalt sker automatisk inden for to uger. Men hvis du ikke vidste, hvad du skulle gøre på det tidspunkt, var tiden allerede ved at løbe ud. Logikken er enkel: På naturligt sprog betyder ”rul tilbage”, ”gå tilbage”, ”gendan”, ”revert” og ”fortryd” ”se tilbage” eller ”gå tilbage til et sikkert sted”. De betyder ikke ”ødelæg historikken”. Kommandoen `git reset --hard` ødelægger den – den omskriver grenen og fjerner commits fra dem, der kan nås gennem HEAD. Et sikkert alternativ er `git checkout `, som opretter en detached HEAD og lader dig se den gamle tilstand uden at røre grenene. Det vigtigste praktiske råd er at lave en `git commit` af den aktuelle tilstand før enhver større opgave, især før refaktorering af flere filer. En commit betyder, at en Claude-fejl kan rettes med én `git checkout .`-kommando uden at miste arbejde. ## Hvordan redder git reflog dig efter en destruktiv reset?
Vigtige punkter `git reflog` viser den lokale historik over alle HEAD-bevægelser i repoet – også commits, der er fjernet med `git reset --hard` eller force-push. Hver bevægelse gemmes som standard i 90 dage. Hvis Claude (eller du eller en anden) ødelagde commits med en destruktiv kommando, viser `git reflog` deres hasher, og du kan gendanne grenen med `git reset --hard `.
Efter et destruktivt reset skal du straks køre `git reflog`: ```bash git reflog ``` Outputtet ser sådan ud: ``` 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}` til `HEAD@{3}` er netop de ”ødelagte” commits. De er ikke forsvundet fra gits lokale objektlager; de er blot blevet utilgængelige gennem grenen. Sådan gendanner du dem: ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Derefter indeholder grenen igen hele historikken frem til katastrofen. **Begrænsninger ved reflog:** 1. **Kun lokalt.** Reflog gemmes i `.git/logs/HEAD`; den findes ikke i fjernrepoet. Hvis du laver force-push og derefter sletter din lokale kopi af repoet, følger reflog med mappen. 2. **90 dage som standard.** Ældre poster kan blive fjernet af git gc. Du kan konfigurere det med `git config gc.reflogExpire 200.days.ago`. 3. **Dækker ikke det, der aldrig var i HEAD.** Hvis en commit kun var i stash, og stashen blev ødelagt, viser reflog kun stashens seneste tilstand, ikke dens interne historik. **Regel for teamet:** Kør aldrig `git gc --aggressive` lige efter en katastrofe. Undersøg først med reflog og gendan; gør alt andet bagefter. Slet heller aldrig den lokale repo-klon, før du er sikker på, at alt, du har brug for, er blevet pushet. ## Hvordan beskytter du et projekt mod destruktive git-kommandoer via CLAUDE.md?
Vigtige punkter Tilføj en instruktionsblok i projektets `CLAUDE.md`, der definerer, hvilke git-kommandoer Claude må køre selv, hvilke der kræver udtrykkelig bekræftelse, og hvilke der er forbudt uden en præcis formulering fra brugeren. Claude behandler CLAUDE.md som projektets systemprompt og følger som standard disse regler. Så bliver én ”farlig” prompt til to sikre kommandoer.
Sårbarheden er, at Claude som standard ikke har nogen beskyttende kontekst. Det fortolker ”rul tilbage” som `git reset --hard`, fordi det teknisk set er en gyldig metode. Læg beskyttelsen i `CLAUDE.md` – projektets systempromptfil. **Minimal regel** (indsæt i din `CLAUDE.md`): ```markdown ## Git Safety Protocol - NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless I explicitly request these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work. - When I say "roll back", "go back", "restore", "revert", "undo" - interpret as REVIEW commands: use `git log`, `git diff`, `git checkout ` (creates detached HEAD), or `git stash` (preserves changes). - ALWAYS ask for confirmation before ANY command that: - Changes HEAD position to a different commit on a branch - Modifies commit history - Could lose uncommitted work - Includes flags --hard, --force, --aggressive - Before any destructive command, output a numbered comparison: - SAFE: use `git checkout ` to view temporarily - DESTRUCTIVE: use `git reset --hard` to permanently destroy - Wait for my explicit choice before executing. ``` **Udvidet regel** for teamet (tilføj i repoets `CLAUDE.md` i roden): ```markdown ## Git Workflow Rules - Lav en commit ved hver fungerende milepæl. Kør `git status` og `git diff` før en WIP-commit, stage kun udtrykkeligt gennemgåede navngivne filer med `git add -- path/to/file`, og gennemgå derefter den staged diff før commit. En timer er en påmindelse om gennemgang, ikke tilladelse til at stage hele arbejdstræet. - Never use `git add .` or `git add -A` for commits by Claude. Only specify files by name, after `git status` + `git diff`. - Before `git push --force` to main—stop and ask me. In feature branches, force-push cautiously, only if you're sure I'm willing to lose the previous version. - When resolving merge conflicts, never choose "ours" or "theirs" immediately—show me both versions first, then I'll decide. - `.gitignore` must contain `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. If they're missing, add them. ``` Når disse blokke er tilføjet, ville formuleringen ”rul tilbage til den seneste push” føre til dette svar næste gang: > Jeg kan se 3 ikke-committede filer og 4 commits siden den seneste push. To muligheder: > > 1. SIKKERT: Opret grenen `view-last-push` via `git checkout ` – jeg bevarer alt arbejdet, men viser midlertidigt tilstanden fra pushen. > 2. DESTRUKTIVT: `git reset --hard ` – jeg ødelægger 4 commits og de ikke-committede ændringer permanent. De kan kun gendannes via `git reflog` inden for 90 dage. Hvad vælger du? Det er et halvt minuts samtale i stedet for fire timers tabt arbejde. ## Hvad er de 5 måder at fortryde på i Claude Code, og hvordan vælger du den rigtige?
Vigtige punkter Hvis noget går galt, er der fem niveauer af nød: `/rewind` (i en session), `git checkout .` (ikke-committede ændringer), `git checkout ` (gå tilbage til en gammel commit uden at miste historik), `git reset --hard ` (flyt grenen tilbage og mist commits foran den), `git reflog` + gendannelse (katastrofe, alt er væk). Hvert niveau er mere omfattende og farligere end det foregående.
Scenariet ”Claude ødelagde det, jeg skal gendanne det hurtigst muligt” følger denne stige nedefra og op. Start altid på niveau 1. **Niveau 1. `/rewind` – øjeblikkelig fortrydelse i en session.** Tryk på `Esc Esc`, eller skriv `/rewind`. Vælg punktet før fejlen. Vælg en tilstand (normalt `Restore code and conversation`). Et sekund senere er du tilbage i fortiden og kan begynde forfra. Dækker 80% af tilfældene, hvor ”Claude gjorde noget forkert”. **Niveau 2. `git checkout .` – fortryd alle ikke-committede ændringer.** ```bash git diff # first see what actually changed git checkout . # undo all uncommitted changes in all files # or selectively: git checkout -- path/to/file.ts # only one file ``` Nyttigt, når `/rewind` ikke virkede (for eksempel fordi Claude ændrede filer via bash), eller når du skal fortryde ændringer uden for sessionshistorikken. Alle ændringer, der ikke blev committet, forsvinder permanent. Hvis du kan komme til at fortryde det, skal du først køre `git stash` (se niveau 2.5). **Niveau 2.5. `git stash` – læg dine ændringer på hylden.** ```bash git stash save "might still need this" # return to a clean state (without changes) # ... # if you change your mind—restore from stash: git stash pop ``` Et godt kompromis mellem ”mist det for altid” og ”lad det være”. Stashen forbliver lokal, indtil den ryddes eksplicit. **Niveau 3. `git checkout ` – gå tilbage til en gammel commit uden at miste historik.** ```bash git log --oneline # find the hash of the right commit, e.g. abc1234 git checkout abc1234 # detached HEAD—view without changing anything # like the state? create a branch from it: git checkout -b recovery abc1234 # return: git checkout main ``` Dette er en sikker, midlertidig tilbagerulning. Detached HEAD ændrer ikke grenen; dit aktuelle arbejde i `main` (eller den gren, du var på) forbliver intakt. Opret en gren, hvis du vil arbejde videre med denne tilstand. **Niveau 4. `git reset --hard ` – flyt grenen tilbage til et punkt.** ⚠️ Destruktivt. Commits foran den angivne hash bliver forældreløse. ```bash git reflog # note the hash of the current state git reset --hard abc1234 # rewrite the branch # found a mistake? return through reflog: git reset --hard HEAD@{1} # to where you were before the reset ``` Brug det kun, hvis du er sikker på, at du ikke har brug for commits foran punktet. Tjek altid `git reflog` FØR reset, så du ved, hvor du kan vende tilbage til, hvis du ombestemmer dig. **Niveau 5. `git reflog` + gendannelse – en katastrofesituation.** Nogen (Claude, dig eller en kollega) har allerede kørt `git reset --hard` eller force-pushet og slettet arbejdet. Hvad gør du? ```bash git reflog # look for the last hash before the disaster git branch recovered HEAD@{N} # create a branch from it git checkout recovered # switch to it git diff main # compare with the current state git checkout main && git merge recovered # restore into main, if you're sure ``` Hvis reflog allerede er blevet ryddet (efter 90 dage som standard), er sidste udvej `git fsck --lost-found`, som viser dangling commits i `.git/objects/`. Det er nærmest arkæologi, men nogle gange virker det. **Regel for valg af niveau:** | Hvad skete der | Niveau | |-----------------------------------------------|-----------------------------| | Claude skrev 3 filer om på den forkerte måde | 1\. `/rewind` | | Jeg prøvede det, kunne ikke lide det, og sessionen hjælper ikke | 2\. `git checkout .` | | Jeg ødelagde det manuelt, vil nødig miste det og vil måske gendanne det | 2.5. `git stash` | | Jeg committede; skal tilbage én commit | 3\. `git checkout ` | | Jeg er sikker på, at jeg ikke har brug for commits foran punktet | 4\. `git reset --hard` | | Det er allerede blevet slettet med en destruktiv kommando | 5\. `git reflog` | ## Hvordan beskytter du et projekt, så der ikke er noget at fortryde?
Vigtige punkter Den bedste fortrydelse er den, du ikke behøver. Tre beskyttelsesregler: gennemgå fremdriften hvert 30. minut, og commit en fungerende milepæl ved kun udtrykkeligt at stage gennemgåede stier; medtag de nødvendige linjer `.claude/personal/` og `.env*` i `.gitignore`; lav større eksperimenter i en separat gren med `git checkout -b experiment-`. Det indsnævrer gendannelsesgabet for committede filer; eksterne systemer og arbejde uden commit kræver stadig deres egen gendannelsesplan.
**Regel 1. Lav en commit hvert 30. minut.** Vent ikke, til ”opgaven er færdig”. Lav en commit af hvert mellemliggende trin, der virker. Commitbeskeder kan være hvad som helst; det vigtigste er, at Claude (eller du) kan vende tilbage til en fungerende tilstand med én `git checkout`-kommando. ```bash # at the beginning of a task git status # inspect all staged and unstaged paths git diff # review the changes # Replace this example path with the actual file you reviewed. git add -- path/to/file.ts git diff --cached # verify exactly what will be committed git commit -m "wip: starting User schema migration" # after 30 minutes (or after the first working iteration) git status git diff git add -- path/to/file.ts # actual reviewed path, not a directory wildcard git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # at the end of the task—a meaningful commit git reset --soft HEAD~2 # combine the three wip commits into one git commit -m "feat(auth): add lastLoginAt field to User table" ``` Hvis du tilføjer en PostToolUse-påmindelse, skal samme gennemgang og regel om staging af udtrykkelige stier gælde. Gør ikke en timer til en ukontrolleret automatisk commit: Ellers kan uvedkommende ændringer eller allerede staged filer komme med i committen. **Regel 2. Minimal `.gitignore`.** Disse linjer skal være i projektets rod: ```gitignore # secrets .env .env.local .env.*.local # local Claude Code settings (not pushed to the team repository) .claude/personal/ .claude/sessions/ .claude/file-history/ # dependencies and build node_modules/ dist/ .next/ build/ ``` Jeg bruger mappen `.claude/personal/` til mine egne eksperimenter og noter, som ikke må med i det delte repository. Mapperne `.claude/sessions/` og `.claude/file-history/` er Claude Codes lokale lagring; de hører ikke hjemme i repoet, fylder meget og er knyttet til en bestemt maskine. **Regel 3. Eksperimenter i en separat gren.** Hvis opgaven er stor (refaktorering af 10+ filer, migrering til en ny database, omskrivning af et modul), skal du ikke gøre det på hovedgrenen: ```bash git checkout -b experiment/auth-rewrite # work, commit every 30 minutes # if it works: git checkout main git merge experiment/auth-rewrite # if it doesn't: git checkout main git branch -D experiment/auth-rewrite # delete the branch # that's it, the main branch is intact ``` Denne enkle vane gør ”Claude ødelagde projektet” til ”Claude ødelagde én gren, jeg slettede den, og vi begynder igen”. **Regel 4. Brug `git tag` før farlige handlinger.** Opret et tag før en databasemigrering, en større refaktorering eller en afhængighedsopdatering: ```bash git tag pre-prisma-migration-v2 # work # something went wrong: git reset --hard pre-prisma-migration-v2 # or just take a look: git checkout pre-prisma-migration-v2 ``` Et tag er en navngiven peger til en commit, som du ikke mister, selv når reflog ryddes. ## Hvad nu: hvordan passer fortrydelse ind i kontekstteknik?
Vigtige punkter Fortrydelse er ikke en separat færdighed, men en del af håndteringen af Claude Code-sessionens kontekst. Når du ved, hvornår du skal trykke på `/rewind`, hvornår du skal lave `git commit`, og hvornår du skal bruge `git stash`, håndterer du et helt arbejdsforløb, ikke bare én kommando. Dette er en del af **Context Engineering**. Uden det opfører Claude sig som en almindelig assistent; med det som et forudsigeligt værktøj.
Disse tre niveauer for at fortryde er infrastrukturen for én færdighed: at vide, hvordan man gendanner en tilstand, når noget går galt. Færdigheden er snæver i sig selv. Men sammen med andre værktøjer til kontekstteknik bliver den til noget mere. Plan Mode lader dig ikke skrive kode med det samme – først kommer planen, så bekræftelsen og derefter udførelsen. Det er forebyggende fortrydelse: Du skriver ikke noget, du senere skal fortryde, fordi planen blev gennemgået på forhånd. Læs mere i guiden om [Plan Mode i Claude Code](https://ailoot.ai/blog/da/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/da/claude-md-template/) fastsætter regler, som Claude følger som standard, herunder Git Safety Protocol, som vi gennemgik ovenfor. Det er forebyggende beskyttelse mod destruktive kommandoer. [Second Brain](https://ailoot.ai/blog/da/claude-code-second-brain/) giver Claude hukommelse om projektet mellem sessioner – det ved, hvilken kode du har, hvad forretningslogikken er, og hvilke aftaler der blev indgået tidligere. Jo mere hukommelse, desto mindre sandsynligt er det, at det gør noget forkert. [Skills og subagenter](https://ailoot.ai/blog/da/claude-code-skills-library/) er din metode i kode. Hvis den korrekte git-arbejdsgang bygges ind i en Skill, vil ingen subagent køre `git reset --hard` uden bekræftelse. Og alt dette tilsammen er **Context Engineering**. Håndter konteksten før prompten, ikke under den. Læs mere om [hvad kontekstteknik er](https://ailoot.ai/blog/da/context-engineering/). Fortrydelse er den sidste forsvarslinje. Plan Mode + CLAUDE.md + Second Brain + Skills er de første fire. Når de er sat op, bliver fortrydelse sjælden og hurtig. Når de ikke er, bliver det et dagligt ritual.
### Kilder - [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)
Fortrydelse begynder, hvor planlægningen slutter. [Åbn Ailoot](https://ailoot.ai/). ## Spørgsmål og svar ### Bør et WIP-checkpoint bruge git add .? Nej. Kør `git status` og `git diff`, stage kun de navngivne filer, du har gennemgået, og undersøg derefter `git diff --cached` før commit. Et periodisk checkpoint giver ikke tilladelse til at medtage uvedkommende eller tidligere staged ændringer. ### Kan /rewind fortryde en databasemigrering eller en fjern-API-handling? Nej. Guiden begrænser checkpoints til understøttede filændringer i sessionen. Databaseeffekter, fjern-Git og API-effekter kræver særskilte gendannelsestrin. Brug Git eller en sikkerhedskopi til filer uden for checkpointets dækning. ## Ailoot · Virksomheden og dens projektportefølje Ailoot bygger på solid driftserfaring, en stor kundebase, stabil service og løbende kontrol af KPI. Virksomheden og dens projektportefølje: millioner af kunder; månedligt salg for milliarder. Ailoot bruger denne driftserfaring til API-adgang til AI-funktioner i kundernes produkter, agenter, applikationer og automatiseringer.