Slik angrer du endringer i Claude Code: /rewind og git

Praktisk informasjon om bruk av Ailoot finner du i dokumentasjonen.

Hva betyr det å angre i Claude Code, og hvorfor er ikke tre nivåer nok?#

Jeg aktiverte /rewind i min første uke med Claude Code, da det ødela autentiseringslogikken i prosjektet mitt i løpet av to prompts. Jeg gikk tilbake, trakk pusten og fortsatte. En måned senere oppsto en annen situasjon: Jeg skrev en skjemamigrering, Claude hjalp til, jeg committet, byttet branch — og innså at jeg hadde glemt et nødvendig trinn. /rewind hjalp ikke; økten var allerede en annen. git checkout til forrige commit hjalp. En måned etter det ba jeg agenten ved et uhell om å «rulle alt tilbake til siste push», og den kjørte git reset --hard og ødela tre timers arbeid. git reflog reddet meg — hashene til de ødelagte commitene var fortsatt der.

Disse tre historiene viser tre beskyttelsesnivåer som fungerer forskjellig, fanger opp ulike feil og alle trengs. Denne veiledningen forklarer hvert nivå med kommandoer, begrensninger og eksempler, og viser også hvordan du konfigurerer et prosjekt på forhånd, slik at Claude ikke ødelegger det første gang.

3 nivåer for å angre — hva og når:

Nå går vi gjennom hvert nivå — nøyaktig hva du skal gjøre, fallgruvene og hvordan du konfigurerer alt slik at ingenting må angres fordi ingenting gikk galt.

Hvordan åpner du /rewind: med kommandoen eller Esc-Esc?#

Etter hvert svar tar Claude automatisk et øyeblikksbilde av alle filer det har redigert i økten. Øyeblikksbildene lagres i ~/.claude/file-history/{sessionId}/ og beholdes i opptil 30 dager. De er inkrementelle — bare forskjellene mellom tilstandene lagres, ikke hele filen. Som standard lagres opptil 100 øyeblikksbilder per økt. Det betyr at du i de fleste virkelige prosjekter til enhver tid har en fullstendig historikk over alle endringene Claude har gjort i løpet av arbeidsdagen.

Trykk Esc to ganger mens inndatafeltet er tomt for å åpne tilbakerullingsmenyen:

[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 det står tekst i inndatafeltet, sletter det første dobbelttrykket på Esc teksten og lagrer den i Up-historikken. Dette er nyttig hvis du allerede har begynt å skrive og innser at du må gå tilbake. Et sitat fra Anthropic sin offisielle dokumentasjon:

Kommandoen /rewind gjør det samme — den åpner menyen. Det finnes et alias, /checkpoint, som fører til samme sted. Hvilken metode som er mest praktisk, handler om vane. Jeg bruker Esc Esc — det er raskere og jeg slipper å ta hendene bort fra tastaturet.

6 moduser i Rewind-menyen: hvilken bør du velge, og når?#

Velg et punkt i listen, så kommer du til handlingsmenyen. Seks valg som alle gjør noe forskjellig.

Fullstendig tabell over moduser:

Funksjonen Summarize up to here kom i Claude Code v2.1.139-v2.1.142, utgitt 11.–15. mai 2026, uke 20:

Forskjellen mellom Restore og Summarize er grunnleggende. Restore går tilbake til en tidligere tilstand og angrer alt som skjedde etter det valgte punktet. Summarize angrer ingenting; den komprimerer bare — de opprinnelige meldingene blir værende i økttranskripsjonen som referanse, men bare sammendraget blir igjen i den aktive konteksten. Bruk restore når du vil at det skal være «som om dette aldri skjedde». Bruk summarize når du vil «beholde det, men uten at det tar opp plass i konteksten».

Etter Restore conversation eller Summarize from here kommer den opprinnelige teksten i den valgte prompten tilbake i inndatafeltet — du kan redigere den og sende den på nytt. Etter Summarize up to here er inndatafeltet tomt, og du blir stående på slutten av samtalen.

Hvilke endringer gjør /rewind IKKE om?#

Dette er hovedbegrensningen folk støter på: /rewind viser en grønn hake og sier «tilbakerulling fullført», men prosjektet er fortsatt ødelagt fordi Claude gjorde mer enn å endre filer. La oss se på de tre tilfellene.

1. Bash-kommandoer spores ikke. Hvis Claude kjører rm file.txt eller mv old.txt new.txt i en tur, blir ikke disse endringene tatt med i kontrollpunktet. Anthropic sin dokumentasjon sier uttrykkelig:

Det betyr at /rewind ikke gjenoppretter alt hvis Claude selv sletter, flytter eller kopierer en fil ved hjelp av bash-verktøyet. git checkout eller gjenoppretting fra en sikkerhetskopi kan hjelpe, men det krever mer enn å trykke på to taster.

2. Eksterne redigeringer fanges ikke opp. Hvis du åpner en fil manuelt i VS Code og redigerer noe, eller en annen Claude-økt endrer de samme filene parallelt, kan ikke den første økten se disse endringene. Et kontrollpunkt tas når Claude avslutter en tur i den gjeldende økten. Det som skjer mellom turene, ligger utenfor ansvaret dens.

3. Operasjoner utenfor filer dekkes ikke i det hele tatt. En Prisma-migrering som er brukt via npx prisma migrate dev, endret databaseskjemaet — /rewind ruller den ikke tilbake fordi databasen ligger utenfor prosjektets filsystem. Force-push til origin/main er det samme: commiten ble sendt til den eksterne serveren, og kontrollpunktet henter den ikke tilbake. Et eksternt API-kall som trakk penger eller slettet en oppføring, kan bare angres med API-ets egne mekanismer.

Regel: Hvis en oppgave påvirker noe utenfor prosjektfilene — databasemigreringer, git push, eksterne API-er — må du forberede en separat tilbakerullingsstrategi for hver eksterne virkning. /rewind gjelder bare lokal filhistorikk i den gjeldende økten.

/rewind kontra git: hva er forskjellen, og hvorfor trenger du begge?#

Anthropic sin dokumentasjon beskriver denne kombinasjonen direkte:

Forskjellene i én tabell:

Kombinasjonen er enkel: Når du kommer til en tilstand der «dette fungerer, og jeg vil ikke miste det», lager du en git commit. Mellom commits bruker du /rewind — det går umiddelbart, krever ingen commitmelding og fyller ikke git-historikken med mellomtilstander. Når arbeidet er ferdig, committer du — helst en meningsfull, atomisk commit.

Hvorfor dekker ikke én /rewind hele oppgaven?#

Å angre er ett tilfelle av kontekstteknikk. Administrer øktkonteksten (når du skal committe, når du skal trykke /rewind, hvilke regler du skal legge inn i CLAUDE.md), så får du en forutsigbar Claude som ikke ødelegger prosjektet eller mister arbeid.

Hvorfor er git reset --hard farlig når du ber Claude om å «gå tilbake»?#

En forespørsel om å «lagre den nåværende tilstanden og gå tilbake til siste push» kan føre til disse kommandoene:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # lagret ikke-committede endringer
git reset --hard 35eb731                                                # ødela commitene d63695e..882e618

Den første kommandoen var riktig — den lagret de ikke-committede endringene i stash. Den andre var destruktiv: den skrev om branchen til commiten 35eb731, og alle commits mellom den og 882e618 ble foreldreløse. Som standard blir foreldreløse commits liggende i .git/objects/ til git gc kjøres, noe som vanligvis skjer automatisk innen to uker. Men hvis du ikke visste hva du skulle gjøre da, begynte tiden allerede å jobbe mot deg.

Logikken er enkel: På vanlig språk betyr «gå tilbake», «dra tilbake», «gjenopprett», «reverter» og «angre» å «se tilbake» eller «gå tilbake til et trygt sted». De betyr ikke «ødelegge historikken». Kommandoen git reset --hard ødelegger den — den skriver om branchen og fjerner commits fra dem som er tilgjengelige via HEAD. Et trygt alternativ er git checkout <commit>, som oppretter en detached HEAD og lar deg se den gamle tilstanden uten å berøre branches.

Det viktigste praktiske rådet er å git commit-te gjeldende tilstand før enhver større oppgave, særlig før refaktorering av flere filer. Én commit gjør enhver Claude-tabbe til én git checkout .-kommando uten at du mister arbeid.

Hvordan redder git reflog deg etter en destruktiv reset?#

Etter en destruktiv reset bør du kjøre git reflog med en gang:

git reflog

Resultatet ser slik ut:

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 og med HEAD@{3} er nettopp de «ødelagte» commitene. De har ikke forsvunnet fra git sitt lokale objektlager; de er bare blitt utilgjengelige via branchen. Slik gjenoppretter du dem:

# Opprett en branch fra den siste «ødelagte» commiten
git branch recovered-work 882e618

# Eller bytt direkte til den
git reset --hard 882e618

Etter dette inneholder branchen igjen hele historikken frem til katastrofen.

Begrensninger ved reflog:

1. Bare lokalt. Reflog lagres i .git/logs/HEAD; den finnes ikke i det eksterne repositoryet. Hvis du force-pusher og deretter sletter den lokale kopien av repositoryet, forsvinner reflog med mappen.
2. 90 dager som standard. Eldre oppføringer kan bli fjernet av git gc. Du kan konfigurere dette med git config gc.reflogExpire 200.days.ago.
3. Dekker ikke det som aldri var i HEAD. Hvis en commit bare fantes i stash og stash ble ødelagt, viser reflog bare stashens siste tilstand, ikke dens interne historikk.

Regel for teamet: Kjør aldri git gc --aggressive rett etter en katastrofe. Undersøk først med reflog og gjenopprett; gjør alt annet etterpå. Og slett aldri den lokale klonen av repositoryet før du er sikker på at alt du trenger, er pushet.

Hvordan beskytter du et prosjekt mot destruktive git-kommandoer med CLAUDE.md?#

Sårbarheten er at Claude ikke har noen beskyttende kontekst som standard. Den tolker «gå tilbake» som git reset --hard fordi det teknisk sett er en gyldig metode. Legg beskyttelsen i CLAUDE.md — prosjektets systempromptfil.

Minimal regel (sett inn i CLAUDE.md):

## Git-sikkerhetsprotokoll

- Kjør ALDRI destruktive git-kommandoer (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) med mindre jeg uttrykkelig ber om disse handlingene. Uautoriserte destruktive handlinger er ikke nyttige og kan føre til tapt arbeid.
- Når jeg sier «gå tilbake», «dra tilbake», «gjenopprett», «reverter» eller «angre», skal du tolke det som kommandoer for å GJENNOMGÅ historikken: bruk `git log`, `git diff`, `git checkout <commit>` (oppretter detached HEAD) eller `git stash` (bevarer endringene).
- Be ALLTID om bekreftelse før ENHVER kommando som:
  - Flytter HEAD til en annen commit på en branch
  - Endrer commit-historikken
  - Kan føre til at ikke-committet arbeid går tapt
  - Inneholder flaggene --hard, --force eller --aggressive
- Før en destruktiv kommando skal du vise en nummerert sammenligning:
  - TRYGT: bruk `git checkout <commit>` for å se midlertidig
  - DESTRUKTIVT: bruk `git reset --hard` for å ødelegge permanent
- Vent på mitt uttrykkelige valg før du utfører den.

Utvidet regel for teamet (legg til i repositoryets rot-CLAUDE.md):

## Regler for Git-arbeidsflyt

- Commit ved hver fungerende milepæl. Før en WIP-commit kjører du `git status` og `git diff`, legger bare gjennomgåtte, navngitte filer i staging med `git add -- path/to/file`, og undersøker staged diff før commit. Et tidsvarsel er en påminnelse om gjennomgang, ikke tillatelse til å stage hele arbeidsmappen.
- Bruk aldri `git add .` eller `git add -A` for commits fra Claude. Oppgi bare filer ved navn, etter `git status` + `git diff`.
- Stopp og spør meg før `git push --force` til main. I feature-branches skal du force-pushe forsiktig og bare hvis du er sikker på at jeg er villig til å miste den forrige versjonen.
- Når du løser mergekonflikter, ikke velg «ours» eller «theirs» med en gang — vis meg begge versjonene først, så bestemmer jeg.
- `.gitignore` må inneholde `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. Hvis de mangler, legg dem til.

Når du har lagt inn disse blokkene, vil formuleringen «gå tilbake til siste push» føre til dette svaret:

Jeg ser 3 ikke-committede filer og 4 commits foran siste push. To alternativer:

1. TRYGT: Opprett en view-last-push-branch med git checkout <last-push-hash> — jeg bevarer alt arbeidet, men viser midlertidig tilstanden fra pushen.
2. DESTRUKTIVT: git reset --hard <last-push-hash> — jeg ødelegger 4 commits og de ikke-committede endringene permanent. De kan bare gjenopprettes via git reflog innen 90 dager. Hva velger du?

Det er et halvt minutts samtale i stedet for fire timer tapt arbeid.

Hva er de 5 måtene å angre på i Claude Code, og hvordan velger du riktig metode?#

Scenarioet «Claude ødela det, jeg må gjenopprette det raskt» følger denne stigen nedenfra og opp. Begynn alltid på nivå 1.

Nivå 1. /rewind — angre umiddelbart i en økt.

Trykk Esc Esc eller skriv /rewind. Velg punktet før feilen. Velg en modus (vanligvis Restore code and conversation). Et sekund senere er du tilbake i fortiden og kan begynne på nytt. Dekker 80% av tilfellene der «Claude gjorde feil».

Nivå 2. git checkout . — angre alle ikke-committede endringer.

git diff                    # se først hva som faktisk er endret
git checkout .              # angre alle ikke-committede endringer i alle filer
# eller selektivt:
git checkout -- path/to/file.ts   # bare én fil

Nyttig når /rewind ikke fungerte (for eksempel fordi Claude endret filer via bash), eller når du må angre noe utenfor økthistorikken. Alle endringer som ikke er committet, forsvinner permanent. Hvis du kan komme til å angre, kjør git stash først (se nivå 2.5).

Nivå 2.5. git stash — legg endringene på hylla.

git stash save "might still need this"
# gå tilbake til en ren tilstand (uten endringer)
# ...
# ombestemmer du deg — gjenopprett fra stash:
git stash pop

Et godt kompromiss mellom «miste for alltid» og «la det stå som det er». Stash blir liggende lokalt til den tømmes uttrykkelig.

Nivå 3. git checkout <commit> — gå tilbake til en gammel commit uten å miste historikken.

git log --oneline               # finn hashen til riktig commit, f.eks. abc1234
git checkout abc1234            # detached HEAD — se uten å endre noe
# liker du tilstanden? Opprett en branch fra den:
git checkout -b recovery abc1234
# gå tilbake:
git checkout main

Dette er en trygg «midlertidig retur». Detached HEAD endrer ikke branchen; arbeidet du har nå i main (eller branchen du var på) forblir intakt. Hvis du vil jobbe videre med denne tilstanden, oppretter du en branch.

Nivå 4. git reset --hard <commit> — flytt branchen tilbake til et punkt.

⚠️ Destruktivt. Commits etter den angitte hashen blir foreldreløse.

git reflog                                  # noter hashen til gjeldende tilstand
git reset --hard abc1234                    # skriv om branchen
# fant du en feil? Gå tilbake via reflog:
git reset --hard HEAD@{1}                   # til tilstanden før reset

Bruk bare dette hvis du er sikker på at du ikke trenger commitene etter punktet. Sjekk alltid git reflog FØR reset, slik at du vet hvor du skal gå tilbake hvis du ombestemmer deg.

Nivå 5. git reflog + gjenoppretting — et katastrofescenario.

Noen (Claude, du eller en kollega) har allerede kjørt git reset --hard eller force-push og fjernet arbeidet. Hva gjør du?

git reflog                                          # se etter den siste hashen før katastrofen
git branch recovered HEAD@{N}                       # opprett en branch fra den
git checkout recovered                              # bytt til den
git diff main                                       # sammenlign med gjeldende tilstand
git checkout main && git merge recovered            # gjenopprett til main hvis du er sikker

Hvis reflog allerede er slettet (etter 90 dager som standard), er siste utvei git fsck --lost-found, som viser dangling commits i .git/objects/. Dette er nærmest arkeologi, men noen ganger virker det.

Regel for å velge nivå:

Hvordan beskytter du prosjektet slik at det ikke er noe å angre?#

Regel 1. Commit hvert 30. minutt.

Ikke vent til «oppgaven er ferdig». Commit alle mellomtrinn som fungerer. Commitmeldinger kan være hva som helst; det viktigste er at Claude (eller du) kan gå tilbake til en fungerende tilstand med én git checkout-kommando.

# i begynnelsen av en oppgave
git status                        # undersøk alle staged og unstaged filbaner
git diff                          # gjennomgå endringene
# Erstatt eksempelbanen med den faktiske filen du har kontrollert.
git add -- path/to/file.ts
git diff --cached                 # kontroller eksakt hva som vil committes
git commit -m "wip: starting User schema migration"

# etter 30 minutter (eller etter den første fungerende iterasjonen)
git status
git diff
git add -- path/to/file.ts         # faktisk kontrollert filbane, ikke katalogjokertegn
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# på slutten av oppgaven — en meningsfull commit
git reset --soft HEAD~2           # slå sammen de tre wip-commitene til én
git commit -m "feat(auth): add lastLoginAt field to User table"

Legger du til en PostToolUse-påminnelse, beholder du regelen om gjennomgang og staging av eksplisitte filbaner. Ikke gjør en timer til en ukontrollert automatisk commit. Ellers kan uvedkommende endringer eller allerede staged filer bli med i commiten.

Regel 2. Minimum .gitignore.

Disse linjene må finnes i prosjektets rotmappe:

# hemmeligheter
.env
.env.local
.env.*.local

# lokale Claude Code-innstillinger (skal ikke pushes til teamrepositoryet)
.claude/personal/
.claude/sessions/
.claude/file-history/

# avhengigheter og bygg
node_modules/
dist/
.next/
build/

Jeg beholder mappen .claude/personal/ til egne eksperimenter og notater, som ikke skal være med i det delte repositoryet. Mappene .claude/sessions/ og .claude/file-history/ er Claude Code sin lokale lagring; de hører ikke hjemme i repositoryet, tar mye plass og er knyttet til én bestemt maskin.

Regel 3. Gjør eksperimenter på en separat branch.

Hvis oppgaven er stor (refaktorering av 10+ filer, migrering til en ny database, omskriving av en modul), må du ikke gjøre det på main-branchen:

git checkout -b experiment/auth-rewrite
# jobb, commit hvert 30. minutt
# hvis det fungerer:
git checkout main
git merge experiment/auth-rewrite
# hvis det ikke fungerer:
git checkout main
git branch -D experiment/auth-rewrite     # slett branchen
# ferdig, main-branchen er intakt

Denne enkle vanen gjør «Claude ødela prosjektet» om til «Claude ødela én branch, jeg slettet den, og vi begynner på nytt».

Regel 4. Bruk git tag før farlige operasjoner.

Opprett en tag før en databasemigrering, en stor refaktorering eller en oppdatering av avhengigheter:

git tag pre-prisma-migration-v2
# jobb
# hvis noe går galt:
git reset --hard pre-prisma-migration-v2
# eller bare ta en titt:
git checkout pre-prisma-migration-v2

En tag er en navngitt peker til en commit som du ikke mister, selv om reflog ryddes.

Hva nå: hvordan passer det å angre inn i kontekstteknikk?#

Disse tre nivåene for å angre er infrastrukturen for én ferdighet: å vite hvordan du gjenoppretter en tilstand når noe går galt. Ferdigheten er i seg selv avgrenset. Men sammen med andre verktøy for kontekstteknikk blir den til noe mer.

Plan Mode lar deg ikke skrive kode med én gang — først kommer planen, så bekreftelsen og deretter utførelsen. Dette er forebyggende tilbakerulling: Du skriver ikke noe du senere må angre, fordi planen ble gjennomgått på forhånd. Les mer i veiledningen om Plan Mode i Claude Code.

CLAUDE.md fastsetter regler som Claude følger som standard, inkludert Git-sikkerhetsprotokollen vi gikk gjennom ovenfor. Dette er forebyggende beskyttelse mot destruktive kommandoer.

Second Brain gir Claude prosjektminne mellom økter — den vet hvilken kode du har, hva forretningslogikken er, og hvilke avtaler som ble gjort tidligere. Jo mer minne, desto mindre sannsynlig er det at den gjør noe feil.

Skills og subagents er metodikken din i kode. Hvis riktig git-arbeidsflyt er bygget inn i en Skill, kjører ingen subagent git reset --hard uten bekreftelse.

Alt dette sammen er Context Engineering. Administrer konteksten før prompten, ikke mens du arbeider med den. Les mer om hva kontekstteknikk er.

Å angre er siste forsvarslinje. Plan Mode + CLAUDE.md + Second Brain + Skills er de fire første. Når de er satt opp, blir behovet for å angre sjeldent og går raskt. Når de ikke er det, blir det et daglig ritual.

Å angre begynner der planleggingen slutter.

Åpne Ailoot.