Kako razveljaviti spremembe v Claude Code: /rewind in git

Praktične informacije o uporabi Ailoota so na voljo v dokumentaciji.

Kaj je razveljavitev v Claude Code in zakaj trije nivoji niso dovolj?#

/rewind sem omogočil v prvem tednu uporabe Claude Code, ko mi je v dveh pozivih pokvaril logiko avtentikacije projekta. Izvedel sem rewind, si oddahnil in nadaljeval. Mesec pozneje se je zgodilo nekaj drugega: pisal sem migracijo sheme, Claude mi je pomagal, ustvaril sem commit, zamenjal vejo—in ugotovil, da sem pozabil potreben korak. /rewind ni pomagal—seja je bila že drugačna. Pomagal je git checkout na prejšnji commit. Mesec za tem sem agentu po nesreči rekel: »vrni vse na zadnji push«, agent pa je pognal git reset --hard in uničil tri ure dela. Rešil me je git reflog—hashe uničenih commitov so bili še vedno tam.

Te tri zgodbe predstavljajo tri nivoje zaščite, ki delujejo različno, lovijo različne napake in so vsi potrebni. Ta vodnik razloži vsak nivo, njegove ukaze, omejitve in primere ter pokaže, kako vnaprej nastaviti projekt, da ga Claude ne bo uničil že prvič.

3 nivoji razveljavitve—kaj in kdaj:

V nadaljevanju bomo pregledali vsak nivo—kaj natančno storiti, na katere pasti paziti in kako nastaviti stvari, da ne bo treba ničesar razveljavljati, ker se nič ne bo pokvarilo.

Kako prikličeš /rewind: z ukazom ali Esc-Esc?#

Po vsakem odgovoru Claude samodejno ustvari posnetek vseh datotek, ki jih je uredil v tej seji. Posnetki so shranjeni v ~/.claude/file-history/{sessionId}/ in se hranijo do 30 dni. So inkrementalni—shranjene so samo razlike med stanji, ne celotna datoteka. Privzeto se na sejo shrani do 100 posnetkov. To pomeni, da imaš v večini resničnih projektov kadar koli na voljo celotno zgodovino vseh Claudeovih sprememb v delovnem dnevu.

Meni za povrnitev odpreš tako, da dvakrat pritisneš Esc, ko je vnosno polje prazno:

[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)
  ...

Če je v vnosnem polju besedilo, ga prvi dvojni pritisk Esc izbriše in shrani v zgodovino Up. To je uporabno, ko si že začel tipkati in ugotoviš, da moraš izvesti rewind. Tukaj je citat iz uradne dokumentacije Anthropic:

Ukaz /rewind naredi isto—odpre meni. Obstaja tudi alias /checkpoint, ki vodi na isto mesto. Kateri način je priročnejši, je stvar navade. Sam uporabljam Esc Esc—hitrejši je in rok mi ni treba umakniti s tipkovnice.

6 načinov v meniju Rewind: katerega izbrati in kdaj?#

Izberi točko na seznamu in prikazal se bo meni dejanj. Vsebuje šest elementov, vsak naredi nekaj drugega.

Celotna tabela načinov:

Funkcija Summarize up to here se je pojavila v Claude Code v2.1.139-v2.1.142, izdanem med 11. in 15. majem 2026, v 20. tednu:

Razlika med Restore in Summarize je temeljna. Restore se vrne v prejšnje stanje in razveljavi vse, kar se je zgodilo po izbrani točki. Summarize ničesar ne razveljavi; samo stisne—izvirna sporočila ostanejo v prepisu seje za referenco, v aktivnem kontekstu pa ostane samo povzetek. Uporabi restore, če želiš, da je »kot da se to nikoli ni zgodilo«. Uporabi summarize, če želiš »to ohraniti, vendar ne porabljati prostora v kontekstu«.

Po Restore conversation ali Summarize from here se izvirno besedilo izbranega poziva vrne v vnosno polje—lahko ga urediš in znova pošlješ. Po Summarize up to here je vnosno polje prazno, ti pa ostaneš na koncu pogovora.

Katerih sprememb /rewind NE razveljavi?#

To je glavna omejitev, na katero naletijo ljudje: /rewind pokaže zeleno kljukico in sporoči »povrnitev je uspela«, projekt pa je še vedno pokvarjen, ker je Claude spremenil več kot samo datoteke. Oglejmo si te tri primere.

1. Ukazi Bash se ne spremljajo. Če Claude v enem koraku izvede rm file.txt ali mv old.txt new.txt, te spremembe ne bodo vključene v checkpoint. Dokumentacija Anthropic to izrecno navaja:

To pomeni, da /rewind ne bo obnovil vsega, če Claude sam izbriše, premakne ali kopira datoteko z orodjem bash. Pomaga lahko git checkout ali obnovitev iz varnostne kopije, vendar je za to potrebnega več kot pritisk dveh tipk.

2. Zunanje urejanje ostane neopaženo. Če ročno odpreš datoteko v VS Code in jo urediš ali pa druga seja Claude vzporedno spreminja iste datoteke, prva seja teh sprememb ne vidi. Posnetek checkpointa nastane, ko Claude konča korak v trenutni seji. Dogajanje med koraki ni njegova odgovornost.

3. Operacije zunaj datotek sploh niso zajete. Migracija Prisma, uporabljena z npx prisma migrate dev, spremeni shemo podatkovne baze—/rewind je ne bo razveljavil, ker je podatkovna baza zunaj datotečnega sistema projekta. Enako velja za force-push na origin/main: commit je šel na oddaljeni strežnik, checkpoint pa ga ne bo vrnil. Oddaljeni klic API-ja, ki je zaračunal denar ali izbrisal zapis, je mogoče razveljaviti samo z lastnimi mehanizmi API-ja.

Pravilo: Če opravilo vpliva na karkoli zunaj projektnih datotek—migracije podatkovne baze, git push, oddaljene API-je—vnaprej pripravi ločeno strategijo povrnitve za vsak zunanji učinek. /rewind je samo lokalna zgodovina datotek znotraj trenutne seje.

/rewind in git: v čem se razlikujeta in zakaj potrebuješ oba?#

Dokumentacija Anthropic to povezavo jasno opredeli:

Razlike v eni tabeli:

Kombinacija je preprosta: vsakič, ko dosežeš stanje »to deluje in tega nočem izgubiti«, ustvari git commit. Med commiti se zanašaj na /rewind—je takojšen, ne potrebuje sporočila commita in ne polni zgodovine gita z vmesnimi stanji. Ko je delo končano, ustvari commit—po možnosti smiseln in atomski.

Zakaj en sam /rewind ne pokrije celotnega opravila?#

Razveljavitev je eden od primerov inženiringa konteksta. Upravljaj kontekst seje (kdaj ustvariti commit, kdaj pritisniti /rewind, katera pravila dodati v CLAUDE.md) in Claude bo predvidljiv ter ne bo uničeval projekta ali izgubljal dela.

Zakaj je git reset --hard nevaren, ko Claude prosiš, naj se »vrne«?#

Prošnja, naj »shrani trenutno stanje in se vrne na zadnji push«, lahko privede do teh ukazov:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # saved uncommitted changes
git reset --hard 35eb731                                                # destroyed commits d63695e..882e618

Prvi ukaz je bil pravilen—shranil je necommitane spremembe v stash. Drugi je bil uničujoč: vejo je prepisal na commit 35eb731, vsi commiti med njim in 882e618 pa so postali osiroteli. Osiroteli commiti privzeto ostanejo v .git/objects/, dokler se ne izvede git gc, kar se običajno samodejno zgodi v dveh tednih. Če pa takrat nisi vedel, kaj storiti, je čas že delal proti tebi.

Logika je preprosta: v naravnem jeziku »vrni«, »pojdi nazaj«, »obnovi«, »povrni« in »razveljavi« pomenijo »poglej prejšnje stanje« ali »vrni se na varno mesto«. Ne pomenijo »uniči zgodovino«. Ukaz git reset --hard jo uniči—prepiše vejo in odstrani commite iz dosegljivih prek HEAD. Varna alternativa je git checkout <commit>, ki ustvari detached HEAD in ti omogoči ogled starega stanja, ne da bi se dotaknil vej.

Glavni praktični nauk je, da pred vsakim obsežnejšim opravilom ustvariš git commit trenutnega stanja, zlasti pred refaktoriranjem več datotek. En commit spremeni vsako Claudeovo napako v en ukaz git checkout ., ne da bi izgubil delo.

Kako te git reflog reši po uničujočem resetu?#

Po uničujočem resetu takoj poženi git reflog:

git reflog

Izhod je videti takole:

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} do HEAD@{3} so prav ti »uničeni« commiti. Niso izginili iz lokalnega shrambe objektov gita; prek veje so samo postali nedosegljivi. Obnoviš jih tako:

# Create a branch from the last “destroyed” commit
git branch recovered-work 882e618

# Or switch directly
git reset --hard 882e618

Po tem veja znova vsebuje vso zgodovino do katastrofe.

Omejitve Refloga:

1. Samo lokalno. Reflog je shranjen v .git/logs/HEAD; na oddaljenem repozitoriju ga ni. Če izvedeš force-push in nato izbrišeš lokalno kopijo repozitorija, reflog izgine skupaj z mapo.
2. Privzeto 90 dni. Starejše vnose lahko odstrani git gc. Nastaviš ga lahko z git config gc.reflogExpire 200.days.ago.
3. Ne zajema tega, česar nikoli ni bilo v HEAD. Če je bil commit samo v stashu in je bil stash uničen, bo reflog prikazal le zadnje stanje stash-a, ne njegove notranje zgodovine.

Pravilo za ekipo: po katastrofi nikoli takoj ne zaženi git gc --aggressive. Najprej razišči stanje z reflogom in obnovi podatke; vse drugo naredi pozneje. In ne izbriši lokalnega klona repozitorija, dokler nisi prepričan, da je bilo vse potrebno potisnjeno.

Kako zaščitiš projekt pred uničujočimi ukazi git prek CLAUDE.md?#

Ranljivost je v tem, da Claude privzeto nima zaščitnega konteksta. »Vrni se« razume kot git reset --hard, ker je to tehnično veljavna metoda. Zaščito dodaj v CLAUDE.md—datoteko s sistemskim pozivom projekta.

Minimalno pravilo (vstavi v svoj CLAUDE.md):

## 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 <commit>` (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 <commit>` to view temporarily
  - DESTRUCTIVE: use `git reset --hard` to permanently destroy
- Wait for my explicit choice before executing.

Razširjeno pravilo za ekipo (dodaj v CLAUDE.md v korenu repozitorija):

## 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.

Po dodajanju teh blokov bi naslednja fraza »vrni se na zadnji push« privedla do takega odgovora:

Vidim 3 necommitane datoteke in 4 commite po zadnjem pushu. Na voljo sta dve možnosti:

1. VARNO: ustvarim vejo view-last-push z ukazom git checkout <last-push-hash>—ohranil bom vse delo, vendar začasno prikazal stanje zadnjega push-a.
2. UNIČUJOČE: git reset --hard <last-push-hash>—trajno bom uničil 4 commite in necommitane spremembe. Obnoviti jih bo mogoče samo prek git reflog v 90 dneh. Kaj izbereš?

To pomeni pol minute pogovora namesto štirih ur izgubljenega dela.

Katerih je 5 načinov za razveljavitev v Claude Code in kako izbrati pravega?#

Scenarij »Claude je nekaj pokvaril, nujno moram obnoviti« rešuješ po lestvi od spodaj navzgor. Vedno začni na 1. stopnji.

1. stopnja. /rewind—takojšnja razveljavitev znotraj seje.

Pritisni Esc Esc ali vpiši /rewind. Izberi točko pred napako. Izberi način (običajno Restore code and conversation). Sekundo pozneje si spet v preteklosti in lahko začneš znova. Pokrije 80 % primerov »Claude je naredil napačno stvar«.

2. stopnja. git checkout .—razveljavitev vseh necommitiranih sprememb.

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

Uporabno, kadar /rewind ni deloval (na primer, Claude je datoteke spreminjal prek bash) ali ko moraš razveljaviti spremembe zunaj zgodovine seje. Vse, kar ni bilo commitano, bo trajno izginilo. Če bi ti bilo to lahko žal, najprej zaženi git stash (glej 2.5. stopnjo).

2.5. stopnja. git stash—odloži spremembe na polico.

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

Dober kompromis med »za vedno izgubi« in »pusti, kot je«. Stash ostane lokalno, dokler ga izrecno ne počistiš.

3. stopnja. git checkout <commit>—vrnitev na stari commit brez izgube zgodovine.

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

To je varna »začasna vrnitev«. Detached HEAD ne spremeni veje; tvoje trenutno delo v main (ali veji, na kateri si bil) ostane nedotaknjeno. Če želiš delati v tem stanju, ustvari vejo.

4. stopnja. git reset --hard <commit>—premik veje nazaj na določeno točko.

⚠️ Uničujoče. Commita, novejša od navedenega hasha, postaneta osirotela.

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

Uporabi samo, če si prepričan, da ne potrebuješ novejših commitov. Pred resetom vedno preveri git reflog, da veš, kam se lahko vrneš, če si premisliš.

5. stopnja. git reflog + obnovitev—katastrofalni scenarij.

Nekdo (Claude, ti ali sodelavec) je že pognal git reset --hard ali izvedel force-push in izbrisal delo. Kaj storiš?

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

Če je bil reflog že počiščen (privzeto po 90 dneh), je zadnja možnost git fsck --lost-found, ki prikaže viseče commite v .git/objects/. To je skoraj arheologija, vendar včasih deluje.

Pravilo za izbiro stopnje:

Kako zaščitiš projekt, da ne bo ničesar treba razveljavljati?#

Pravilo 1. Commit naredi vsakih 30 minut.

Ne čakaj, da bo »naloga končana«. Commitaj vsak vmesni korak, ki deluje. Sporočila commitov so lahko poljubna; glavno je, da se Claude (ali ti) z enim ukazom git checkout lahko vrne v delujoče stanje.

# 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"

Če dodaš opomnik PostToolUse, ohrani isto pravilo pregleda in priprave izrecnih poti. Časovnika ne spremeni v nenadzorovan samodejni commit: vanj bi sicer lahko vstopile nepovezane spremembe ali že pripravljene datoteke.

Pravilo 2. Minimalni .gitignore.

Te vrstice morajo biti v korenu projekta:

# 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/

Mapo .claude/personal/ hranim za lastne poskuse in zapiske, ki ne smejo biti vključeni v skupni repozitorij. Mapi .claude/sessions/ in .claude/file-history/ sta lokalna shramba Claude Code; ne sodita v repozitorij, zavzameta veliko prostora in sta vezani na določen računalnik.

Pravilo 3. Poskusi na ločeni veji.

Če je naloga obsežna (refaktoriranje 10+ datotek, migracija na novo podatkovno bazo, prepis modula), je ne opravljaj na glavni veji:

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

Ta preprosta navada spremeni »Claude je uničil projekt« v »Claude je uničil eno vejo, izbrisal sem jo in začnemo znova«.

Pravilo 4. Pred nevarnimi operacijami uporabi git tag.

Pred migracijo podatkovne baze, obsežnim refaktoriranjem ali posodobitvijo odvisnosti ustvari tag:

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

Tag je poimenovan kazalec na commit, ki ga ne boš izgubil niti po čiščenju refloga.

Kaj sledi: kako se razveljavitev povezuje z inženiringom konteksta?#

Ti trije nivoji razveljavitve so infrastruktura za eno veščino: znati obnoviti stanje, ko se kaj pokvari. Ta veščina je sama po sebi ozka. V povezavi z drugimi orodji inženiringa konteksta pa postane nekaj več.

Plan Mode ti ne dovoli, da takoj pišeš kodo—najprej pripraviš načrt, nato sledi potrditev in šele potem izvedba. To je preventivna razveljavitev: ne napišeš nečesa, kar boš pozneje moral razveljaviti, ker je bil načrt vnaprej pregledan. Več preberi v vodniku Plan Mode v Claude Code.

CLAUDE.md določa pravila, ki jih Claude privzeto upošteva, vključno s protokolom Git Safety Protocol, ki smo ga obravnavali zgoraj. To je preventivna zaščita pred uničujočimi ukazi.

Second Brain Claudeu med sejami zagotavlja spomin o projektu—ve, kakšno kodo imaš, kakšna je poslovna logika in o čem ste se dogovorili prej. Več spomina pomeni manjšo verjetnost, da bo naredil kaj narobe.

Skills in podagenti so tvoja metodologija v kodi. Če je pravilen potek dela z gitom vgrajen v Skill, noben podagent ne bo brez potrditve pognal git reset --hard.

Vse to skupaj je Context Engineering. Kontekst upravljaj pred pozivom, ne med njim. Več preberi v članku kaj je inženiring konteksta.

Razveljavitev je zadnja obrambna linija. Plan Mode + CLAUDE.md + Second Brain + Skills so prve štiri. Ko so nastavljeni, je razveljavitev redka in hitra. Če niso, postane vsakodnevni ritual.

Razveljavitev se začne tam, kjer se konča načrtovanje.

Odpri Ailoot.