# Så ångrar du ändringar i Claude Code: /rewind och git > Återställningslägen, begränsningar för kontrollpunkter, git checkout, stash, reflog och skydd mot destruktiva kommandon. Fem sätt att återställa ett tillstånd. Source: https://ailoot.ai/blog/sv/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/sv/claude-code-undo-changes/ Language: sv Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-4013168e9eaf0bf8afd5065e6d24db4a537f238b9bbafeb6fd21c94f6f7b898d [Praktisk information om att arbeta med Ailoot finns i dokumentationen](https://ailoot.ai/docs/). ## Vad innebär ångra i Claude Code, och varför räcker inte tre nivåer?
Det viktigaste Det finns tre nivåer för att ångra i Claude Code: det inbyggda kommandot `/rewind` (omedelbar återställning i en session), `git checkout` (återställning till den senaste commiten) och `git reflog` (ett katastrofskydd om någon har kört `git reset --hard`). Varje nivå täcker sin egen typ av misstag och inget utanför sina gränser. Om du bara känner till `/rewind` står du där med byxorna nere vid det första allvarliga misstaget.
Jag började använda `/rewind` under min första vecka med Claude Code, när det förstörde autentiseringslogiken i projektet med två promptar. Jag backade, drog en suck av lättnad och fortsatte. En månad senare uppstod en ny situation: jag skrev en schemamigrering, Claude hjälpte till, jag gjorde en commit, bytte gren och insåg att jag hade glömt ett nödvändigt steg. `/rewind` hjälpte inte – sessionen var redan en annan. `git checkout` till den föregående commiten löste det. En månad därefter sa jag av misstag till agenten: ”rulla tillbaka allt till den senaste pushen”, och den körde `git reset --hard`, vilket förstörde tre timmars arbete. `git reflog` räddade mig – hasharna för de förstörda committen fanns fortfarande kvar. De här tre berättelserna handlar om tre skyddsnivåer som fungerar på olika sätt, fångar olika misstag och alla behövs. Den här guiden går igenom varje nivå med kommandon, begränsningar och exempel. Den visar också hur du konfigurerar ett projekt i förväg så att Claude inte sänker det första gången. **3 nivåer för att ångra – vad och när:** | Nivå | Kommando | Täcker | Täcker INTE | |----|----|----|----| | 1\. I en session | `/rewind` eller `Esc Esc` | Filer som Claude ändrat med sina egna verktyg; konversationshistorik | Bash-kommandon, externa redigerare, databasmigreringar | | 2\. Före en commit | `git checkout .` eller `git stash` | Alla ej committade filändringar | Committade ändringar | | 3\. Katastrof | `git reflog` + `git reset --hard ` | Commits som förstörts av `reset --hard` eller force-push | Destruktiva bash-kommandon (rm, databasmigreringar) | Nu går vi igenom varje nivå – exakt vad du ska göra, fallgroparna och hur du konfigurerar allt så att inget behöver ångras eftersom inget gick sönder. ## Hur använder du /rewind: med kommandot eller Esc-Esc?
Det viktigaste Det finns två sätt att öppna återställningsmenyn i Claude Code. Det första är att skriva `/rewind` i inmatningsfältet. Det andra är att trycka på `Esc` två gånger när fältet är tomt. Om det finns text i fältet rensar ett dubbeltryck först texten och sparar den i inmatningshistoriken; ytterligare ett dubbeltryck öppnar menyn. Kommandot `/rewind` har aliaset `/checkpoint`.
Efter varje svar tar Claude automatiskt en ögonblicksbild av alla filer som det redigerat i den sessionen. Ögonblicksbilderna lagras i `~/.claude/file-history/{sessionId}/` och sparas i upp till 30 dagar. De är inkrementella – bara skillnaderna mellan tillstånden sparas, inte hela filen. Som standard lagras upp till 100 ögonblicksbilder per session. Det betyder att du i de flesta verkliga projekt när som helst har en fullständig historik över alla ändringar Claude gjort under arbetsdagen. Öppna återställningsmenyn genom att trycka på `Esc` två gånger när inmatningsfältet är 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) ... ``` Om det finns text i inmatningsfältet rensar det första dubbeltrycket på `Esc` texten och sparar den i historiken som du når med `Upp`. Det är användbart om du redan har börjat skriva och inser att du behöver återställa. Ett citat från Anthropics officiella dokumentation:

Om det finns text i promptfältet rensar dubbeltryck på Esc först texten i stället för att öppna menyn. Den rensade texten sparas i inmatningshistoriken, så att du kan återställa den med uppåtpilen efter att återställningsmenyn har öppnats.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Kommandot `/rewind` gör samma sak – det öppnar menyn. Det finns ett alias, `/checkpoint`, som leder till samma plats. Vilket sätt som är smidigast är en vanesak. Jag använder `Esc Esc` – det går snabbare och jag behöver inte flytta händerna från tangentbordet. ## 6 lägen i återställningsmenyn: vilket ska du välja och när?
Det viktigaste När du har valt en återställningspunkt i menyn visas en andra meny med sex lägen. Tre återställer tillstånd (`Restore code and conversation`, `Restore conversation`, `Restore code`), två komprimerar historiken (`Summarize from here`, `Summarize up to here`) och ett avbryter åtgärden (`Never mind`). Det vanligaste scenariot – ”återställ både koden och konversationen” – motsvarar det första alternativet.
Välj en punkt i listan så kommer du till åtgärdsmenyn. Sex alternativ som gör olika saker. **Fullständig tabell över lägen:** | Läge | Vad det gör | När du ska välja det | |----|----|----| | `Restore code and conversation` | Återställer både filer och konversationshistorik till den valda punkten | Det vanligaste scenariot: Claude gick åt fel håll och jag vill börja om med en tydligare formulering | | `Restore conversation` | Återställer bara konversationshistoriken; filerna förblir som de är nu | Koden är bra, men konversationen hamnade fel; jag formulerar om från den här punkten och behåller de aktuella ändringarna | | `Restore code` | Återställer filerna; konversationen förblir som den är | Vissa av Claudes ändringar var onödiga, men jag behöver fortfarande kontexten från konversationen (till exempel för att vi kom överens om nästa steg) | | `Summarize from here` | Komprimerar allt EFTER den valda punkten till en sammanfattning. Rör inte filerna | En lång felsökningssession har fyllt kontexten; jag behöver frigöra utrymme men behålla de ursprungliga instruktionerna i sin helhet | | `Summarize up to here` | Komprimerar allt FÖRE den valda punkten till en sammanfattning. Rör inte filerna | Det fanns en lång inledande genomgång följd av en specifik uppgift – vi komprimerar genomgången till ett meddelande och låter det senaste arbetet vara som det är | | `Never mind` | Stänger menyn utan att göra ändringar | Jag har ändrat mig | Funktionen `Summarize up to here` kom i Claude Code v2.1.139-v2.1.142, som släpptes 11–15 maj 2026, vecka 20:

Du kan komprimera tidig kontext via återställningsmenyn med ”Summarize up to here”.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
Skillnaden mellan `Restore` och `Summarize` är grundläggande. Restore återgår till ett tidigare tillstånd och ångrar allt som hänt efter den valda punkten. Summarize ångrar ingenting; det komprimerar bara – de ursprungliga meddelandena finns kvar i sessionens transkript som referens, men i den aktiva kontexten finns bara sammanfattningen kvar. Använd Restore när du vill att det ska vara ”som om det aldrig hände”. Använd Summarize när du vill ”behålla det, men inte ta upp plats i kontexten”. Efter `Restore conversation` eller `Summarize from here` återkommer den ursprungliga texten från den valda prompten i inmatningsfältet – du kan redigera den och skicka igen. Efter `Summarize up to here` är inmatningsfältet tomt och du befinner dig fortfarande i slutet av konversationen. ## Vilka ändringar återställer /rewind INTE?
Det viktigaste `/rewind` håller bara reda på ändringar som Claude gör med sina egna filredigeringsverktyg. Det kan inte se eller återställa något annat. Det finns tre sorters osynliga ändringar: bash-kommandon (rm, mv, cp), externa redigeringar (dina manuella ändringar i en IDE, ändringar från andra sessioner) och åtgärder utanför filer (databasmigreringar, git push, fjärranrop till API:er).
Det här är den främsta begränsningen som folk stöter på: `/rewind` visar en grön bock och säger ”återställningen lyckades”, men projektet är fortfarande trasigt eftersom Claude gjorde mer än att bara ändra filer. Vi tittar på de tre fallen. **1. Bash-kommandon spåras inte.** Om Claude kör `rm file.txt` eller `mv old.txt new.txt` under en tur ingår inte de ändringarna i kontrollpunkten. Anthropics dokumentation säger uttryckligen:

Kontrollpunkter spårar inte filer som ändrats via bash-kommandon. Om Claude Code till exempel kör rm file.txt, mv old.txt new.txt eller cp source.txt dest.txt går det inte att ångra filändringarna med rewind.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Det betyder att `/rewind` inte återställer allt om Claude själv tar bort, flyttar eller kopierar en fil med bash-verktyget. `git checkout` eller återställning från en säkerhetskopia kan hjälpa, men det kräver mer än två knapptryck. **2. Externa redigeringar fångas inte upp.** Om du öppnar en fil manuellt i VS Code och redigerar något, eller om en andra Claude-session ändrar samma filer parallellt, kan den första sessionen inte se de ändringarna. En ögonblicksbild av kontrollpunkten tas när Claude avslutar en tur i den aktuella sessionen. Det som händer mellan turerna ligger utanför dess ansvar. **3. Åtgärder utanför filer täcks inte alls.** En Prisma-migrering som tillämpas via `npx prisma migrate dev` ändrar databasschemat – `/rewind` kan inte ångra den eftersom databasen ligger utanför projektets filsystem. En force-push till `origin/main` är samma sak: commiten skickades till fjärrservern, och kontrollpunkten återställer den inte. Ett fjärranrop till ett API som debiterade pengar eller tog bort en post kan bara ångras med API:ets egna mekanismer. **Regel:** Om en uppgift påverkar något utanför projektfilerna – databasmigreringar, git push eller fjärranrop till API:er – ska du förbereda en separat återställningsstrategi för varje extern effekt. `/rewind` är bara lokal filhistorik i den aktuella sessionen. ## /rewind jämfört med git: hur skiljer de sig och varför behöver du båda?
Det viktigaste `/rewind` är en lokal återställning i en enda Claude Code-session. Den lagrar inkrementella ögonblicksbilder i upp till 30 dagar, upp till 100 per session. git är projektets långsiktiga historik, delad med teamet, med grenar, mergekonflikter och ett fjärrrepo. Det ena ersätter inte det andra. Bästa praxis är att göra en `git commit` vid varje logisk milstolpe och använda `/rewind` mellan committerna.
Anthropics dokumentation beskriver uttryckligen hur dessa kompletterar varandra:

Kontrollpunkter är utformade för snabb återställning på sessionsnivå. Fortsätt använda ett versionshanteringssystem (till exempel Git) för commits, grenar och långsiktig historik. Kontrollpunkter kompletterar vanlig versionshantering, men ersätter den inte. Tänk på kontrollpunkter som ”lokal ångra-funktion” och Git som ”permanent historik”.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Skillnaderna i en tabell: | Parameter | /rewind | git | |----|----|----| | Finkornighet | Varje tur i konversationen | Varje commit | | Lagring | Upp till 30 dagar, upp till 100 per session, lokalt i `~/.claude/file-history/` | Permanent, i repots `.git/` och på fjärrservern | | Vad det spårar | Claudes ändringar med sina egna verktyg | Alla committade ändringar | | Vad det INTE spårar | Bash, externa redigeringar, migreringar, push | Ej committade ändringar | | Kommando | Ett kommando i Claude | Ett externt versionshanteringssystem | | Återställer konversationen | Ja | Nej | | Fungerar mellan sessioner | Bara inom samma session | Överallt | Kombinationen är enkel: när du når ett läge där ”det här fungerar och jag vill inte förlora det”, gör en `git commit`. Mellan commits använder du `/rewind` – det går direkt, kräver inget commitmeddelande och fyller inte git-historiken med mellanstadier. När arbetet är klart gör du en commit, helst en meningsfull och atomär sådan. ## Varför räcker inte en /rewind för hela uppgiften? Ångra är ett exempel på **kontextteknik**. Hantera sessionskontexten (när du ska committa, när du ska trycka på `/rewind`, vilka regler du ska lägga i `CLAUDE.md`) så får du en förutsägbar Claude som inte förstör projektet eller tappar arbete. ## Varför är `git reset --hard` farligt när du ber Claude att ”rulla tillbaka”?
Det viktigaste På naturligt språk betyder ”rulla tillbaka” att ”titta i historiken”, inte ”förstör den”; Claude bör föreslå `git checkout` som standard, inte `reset --hard`; skyddet konfigureras i CLAUDE.md.
En begäran om att ”spara det aktuella tillståndet och rulla tillbaka till den senaste pushen” kan leda till följande kommandon: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` Det första kommandot var korrekt – det sparade de ej committade ändringarna i stashen. Det andra var destruktivt: det skrev om grenen till commiten `35eb731`, och alla commits mellan den och `882e618` blev föräldralösa. Som standard blir föräldralösa commits kvar i `.git/objects/` tills `git gc` körs, vilket vanligtvis sker automatiskt inom två veckor. Men om du inte visste vad du skulle göra då hade tiden redan börjat rinna ut. Logiken är enkel: på naturligt språk betyder ”rulla tillbaka”, ”gå tillbaka”, ”återställ”, ”revertera” och ”ångra” att ”titta bakåt” eller ”gå tillbaka till en säker plats”. De betyder inte ”förstör historiken”. Kommandot `git reset --hard` förstör den – det skriver om grenen och tar bort commits från dem som går att nå via HEAD. Ett säkert alternativ är `git checkout `, som skapar en frikopplad HEAD och låter dig titta på det gamla tillståndet utan att röra grenarna. Det viktigaste praktiska rådet är att göra en `git commit` av det aktuella tillståndet före varje större uppgift, särskilt innan du refaktorerar flera filer. En commit gör att ett Claude-misstag går att rätta med ett enda `git checkout .` utan att arbetet går förlorat. ## Hur räddar git reflog dig efter en destruktiv reset?
Det viktigaste `git reflog` visar den lokala historiken över alla förflyttningar av HEAD i repot – även commits som tagits bort med `git reset --hard` eller force-push. Varje förflyttning sparas som standard i 90 dagar. Om Claude (eller du eller någon annan) förstörde commits med ett destruktivt kommando visar `git reflog` deras hashar, och du kan återställa grenen med `git reset --hard `.
Kör `git reflog` direkt efter en destruktiv reset: ```bash git reflog ``` Utdata ser ut så här: ``` 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}` till `HEAD@{3}` är just de ”förstörda” committerna. De har inte försvunnit ur gits lokala objektlager; de har bara blivit oåtkomliga via grenen. Så här återställer du dem: ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Därefter innehåller grenen åter all historik fram till katastrofen. **Begränsningar med reflog:** 1. **Bara lokalt.** Reflog lagras i `.git/logs/HEAD`; den finns inte i fjärrrepot. Om du force-pushar och sedan tar bort din lokala repokopia försvinner reflog med mappen. 2. **90 dagar som standard.** Äldre poster kan tas bort av git gc. Du kan konfigurera det med `git config gc.reflogExpire 200.days.ago`. 3. **Täcker inte sådant som aldrig fanns i HEAD.** Om en commit bara fanns i stashen och stashen förstördes visar reflog bara stashens senaste tillstånd, inte dess interna historik. **Regel för teamet:** kör aldrig `git gc --aggressive` direkt efter en katastrof. Undersök först med reflog och återställ; gör allt annat efteråt. Ta heller aldrig bort den lokala repoklonen förrän du är säker på att allt du behöver har pushats. ## Hur skyddar du ett projekt mot destruktiva git-kommandon med CLAUDE.md?
Det viktigaste Lägg till ett instruktionsblock i projektets `CLAUDE.md` som definierar vilka git-kommandon Claude får köra på egen hand, vilka som kräver uttrycklig bekräftelse och vilka som är förbjudna utan en exakt fras från användaren. Claude behandlar CLAUDE.md som projektets systemprompt och följer som standard de här reglerna. Då leder ett ”farligt” prompt till två säkra kommandon.
Sårbarheten är att Claude saknar skyddande kontext som standard. Det tolkar ”rulla tillbaka” som `git reset --hard` eftersom det tekniskt sett är en giltig metod. Lägg in skyddet i `CLAUDE.md` – projektets systempromptfil. **Minimal regel** (lägg in 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. ``` **Utökad regel** för teamet (lägg till i repots `CLAUDE.md` i roten): ```markdown ## Git Workflow Rules - Commit at each working milestone. Before a WIP commit, run `git status` and `git diff`, stage only explicitly reviewed named files with `git add -- path/to/file`, then inspect the staged diff before committing. A timer is a reminder to review, not permission to stage the entire working tree. - 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 det blocket är på plats skulle frasen ”rulla tillbaka till den senaste pushen” nästa gång leda till det här svaret: > Jag ser 3 ej committade filer och 4 commits sedan den senaste pushen. Två alternativ: > > 1. SÄKERT: skapa grenen `view-last-push` med `git checkout ` – jag bevarar allt arbete men visar tillfälligt tillståndet från pushen. > 2. DESTRUKTIVT: `git reset --hard ` – jag förstör permanent 4 commits och de ej committade ändringarna. De kan bara återställas via `git reflog` inom 90 dagar. Vilket alternativ väljer du? Det är en halv minuts samtal i stället för fyra timmars förlorat arbete. ## Vilka är de 5 sätten att ångra i Claude Code, och hur väljer du rätt?
Det viktigaste Om något går fel finns det fem nivåer för hur desperat läget är: `/rewind` (i en session), `git checkout .` (ej committade ändringar), `git checkout ` (återgå till en gammal commit utan att förlora historik), `git reset --hard ` (flytta tillbaka grenen och förlora commits efter punkten), `git reflog` + återställning (katastrof, allt är borta). Varje nivå är tyngre och farligare än den föregående.
Scenariot ”Claude förstörde det, jag måste återställa det snabbt” följer den här stegen från den minst ingripande nivån och uppåt. Börja alltid på nivå 1. **Nivå 1. `/rewind` – ångra direkt i en session.** Tryck på `Esc Esc` eller skriv `/rewind`. Välj punkten före misstaget. Välj ett läge (vanligtvis `Restore code and conversation`). En sekund senare är du tillbaka i det förflutna och kan börja om. Täcker 80% av fallen där ”Claude gjorde fel”. **Nivå 2. `git checkout .` – ångra alla ej committade ändringar.** ```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 ``` Användbart när `/rewind` inte fungerade (till exempel för att Claude ändrade filer via bash) eller när du behöver ångra ändringar utanför sessionens historik. Alla ändringar som inte committats försvinner permanent. Om du tror att du kan ångra dig, kör `git stash` först (se nivå 2.5). **Nivå 2.5. `git stash` – lägg undan ändringarna.** ```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 ``` En bra kompromiss mellan ”förlora för alltid” och ”låta det vara”. Stashen finns kvar lokalt tills den uttryckligen rensas. **Nivå 3. `git checkout ` – återgå till en gammal commit utan att förlora 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 ``` Det här är en säker, tillfällig återgång. En frikopplad HEAD ändrar inte grenen; det aktuella arbetet i `main` (eller vilken gren du använde) förblir intakt. Skapa en gren om du vill fortsätta arbeta med det här tillståndet. **Nivå 4. `git reset --hard ` – flytta grenen tillbaka till en punkt.** ⚠️ Destruktivt. Commits efter den angivna hashen blir föräldralösa. ```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 ``` Använd bara om du är säker på att du inte behöver commits efter punkten. Kontrollera alltid `git reflog` FÖRE reset så att du vet vart du kan återgå om du ångrar dig. **Nivå 5. `git reflog` + återställning – en katastrofsituation.** Någon (Claude, du eller en kollega) har redan kört `git reset --hard` eller force-pushat och raderat arbetet. Vad 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 ``` Om reflog redan har rensats (efter 90 dagar som standard) är sista utvägen `git fsck --lost-found`, som visar hängande commits i `.git/objects/`. Det är närmast arkeologi, men ibland fungerar det. **Regel för att välja nivå:** | Vad hände | Nivå | |-----------------------------------------------|-----------------------------| | Claude skrev om 3 filer på fel sätt | 1\. `/rewind` | | Jag testade, gillade det inte och sessionen hjälper inte | 2\. `git checkout .` | | Jag förstörde det manuellt, vill inte förlora det och kan vilja återställa | 2.5. `git stash` | | Jag committade; behöver gå tillbaka en commit | 3\. `git checkout ` | | Jag är säker på att jag inte behöver commits efter punkten | 4\. `git reset --hard` | | Det har redan raderats med ett destruktivt kommando | 5\. `git reflog` | ## Hur skyddar du ett projekt så att inget behöver ångras?
Det viktigaste Det bästa sättet att ångra är att slippa behöva göra det. Tre skyddsregler: granska framstegen var 30:e minut och checka in en fungerande milstolpe genom att uttryckligen mellanlagra bara granskade sökvägar; ha raderna `.claude/personal/` och `.env*` i `.gitignore`; gör större experiment i en separat gren med `git checkout -b experiment-`. Det minskar återställningsgapet för incheckade filer; externa system och oincheckat arbete behöver fortfarande en egen återställningsplan.
**Regel 1. Gör en commit var 30:e minut.** Vänta inte tills ”uppgiften är klar”. Gör en commit för varje mellanliggande steg som fungerar. Commitmeddelanden kan vara vad som helst; huvudsaken är att Claude (eller du) kan återgå till ett fungerande tillstånd med ett enda `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" ``` Om du lägger till en PostToolUse-påminnelse behåller du samma regel om granskning och uttryckliga filsökvägar. Låt inte en timer bli en okontrollerad automatisk commit: då kan orelaterade eller redan mellanlagrade filer hamna i commiten. **Regel 2. Minsta möjliga `.gitignore`.** De här raderna behövs i projektets rot: ```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/ ``` Jag använder mappen `.claude/personal/` för egna experiment och anteckningar som inte får ingå i det delade repot. Mapparna `.claude/sessions/` och `.claude/file-history/` är Claude Codes lokala lagring; de hör inte hemma i repot, tar mycket plats och är knutna till en viss maskin. **Regel 3. Experimentera i en separat gren.** Om uppgiften är stor (refaktorera 10+ filer, migrera till en ny databas, skriva om en modul), gör det inte i huvudgrenen: ```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 ``` Den här enkla vanan gör att ”Claude förstörde projektet” blir ”Claude förstörde en gren, jag tog bort den och vi börjar om”. **Regel 4. Skapa en `git tag` före farliga åtgärder.** Skapa en tagg före en databasmigrering, en större refaktorering eller en beroendeuppdatering: ```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 ``` En tagg är en namngiven pekare till en commit som du inte förlorar ens när reflog rensas. ## Nästa steg: hur passar ångra in i kontextteknik?
Det viktigaste Att ångra är inte en fristående färdighet utan en del av hanteringen av Claude Code-sessionens kontext. När du vet när du ska trycka på `/rewind`, när du ska göra `git commit` och när du ska använda `git stash`, hanterar du ett helt arbetsflöde, inte ett enskilt kommando. Detta är en del av **Context Engineering**. Utan den fungerar Claude som en vanlig assistent; med den fungerar det som ett förutsägbart verktyg.
De här tre nivåerna för att ångra är grunden för en färdighet: att veta hur man återställer ett tillstånd när något går sönder. Den färdigheten är snäv i sig. Men tillsammans med andra verktyg för kontextteknik blir den något mer. Plan Mode låter dig inte skriva kod direkt – först kommer planen, sedan bekräftelsen och därefter genomförandet. Det är förebyggande ångring: du skriver inte sådant som du senare måste ångra eftersom planen granskades i förväg. Läs mer i guiden om [Plan Mode i Claude Code](https://ailoot.ai/blog/sv/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/sv/claude-md-template/) anger regler som Claude följer som standard, däribland Git Safety Protocol som vi gick igenom ovan. Det är ett förebyggande skydd mot destruktiva kommandon. [Second Brain](https://ailoot.ai/blog/sv/claude-code-second-brain/) ger Claude minne om projektet mellan sessioner – det vet vilken kod du har, hur affärslogiken fungerar och vilka överenskommelser ni gjort tidigare. Ju mer minne, desto mindre sannolikt att det gör fel. [Skills och subagenter](https://ailoot.ai/blog/sv/claude-code-skills-library/) är din metodik i kod. Om rätt git-arbetsflöde byggs in i en Skill kommer ingen subagent att köra `git reset --hard` utan bekräftelse. Allt detta tillsammans är **Context Engineering**. Hantera kontexten före prompten, inte medan du arbetar med den. Läs mer om [vad kontextteknik är](https://ailoot.ai/blog/sv/context-engineering/). Att ångra är den sista försvarslinjen. Plan Mode + CLAUDE.md + Second Brain + Skills är de fyra första. När de är på plats blir ångring sällsynt och går snabbt. När de saknas blir det en daglig rutin.
### Källor - [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)
Ångra börjar där planeringen slutar. [Öppna Ailoot](https://ailoot.ai/). ## Frågor om den här guiden: Så ångrar du ändringar i Claude Code: /rewind och git ### Bör en WIP-checkpoint använda git add .? Nej. Kör `git status` och `git diff`, lägg bara till namngivna filer som du har granskat och kontrollera sedan `git diff --cached` före commit. En regelbunden checkpoint godkänner inte att orelaterade eller tidigare mellanlagrade ändringar tas med. ### Kan /rewind ångra en databasmigrering eller en extern API-åtgärd? Nej. Guiden begränsar checkpoints till filredigeringar i sessionen som stöds. Databas-, fjärr-Git- och API-effekter behöver separata återställningssteg; använd Git eller säkerhetskopia för filer utanför checkpointens täckning. ## Ailoot · Företaget och dess projektportfölj Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll. Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder. Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.