Változtatások visszavonása a Claude Code-ban: /rewind és git

A Ailoot használatával kapcsolatos gyakorlati információk a dokumentációban találhatók.

Mi a visszavonás a Claude Code-ban, és miért nem elég három szint?#

A Claude Code használatának első hetében kapcsoltam be a /rewind parancsot, amikor két prompt alatt tönkretette a projektem hitelesítési logikáját. Visszatekertem, megkönnyebbülten felsóhajtottam, és folytattam a munkát. Egy hónappal később újabb helyzet adódott: adatbázis-séma migrációt írtam, Claude segített, commitoltam, átváltottam egy másik ágra—aztán rájöttem, hogy kihagytam egy szükséges lépést. A /rewind nem segített—a munkamenet már más volt. A korábbi commitra való git checkout segített. Egy hónappal ezután véletlenül azt mondtam az agentnek: „állíts vissza mindent az utolsó push állapotára”, mire lefuttatta a git reset --hard parancsot, és háromórányi munkát tett tönkre. A git reflog megmentett—a megsemmisített commitok hash-ei még megvoltak.

Ez a három történet a védelem három szintjét mutatja be: eltérően működnek, különböző hibákat fognak meg, és mindegyikre szükség van. Ez az útmutató parancsokkal, korlátozásokkal és példákkal magyarázza el az egyes szinteket, és azt is megmutatja, hogyan állíts be előre egy projektet, hogy Claude már az első alkalommal se tehesse tönkre.

A visszavonás 3 szintje—mi és mikor:

Most sorra vesszük mindegyik szintet—pontosan mit kell tenni, milyen buktatók vannak, és hogyan állíthatod be a dolgokat úgy, hogy ne legyen mit visszavonni, mert semmi sem romlott el.

Hogyan hívhatod elő a /rewind parancsot: paranccsal vagy Esc-Esc-vel?#

Minden válasz után Claude automatikusan pillanatképet készít az összes fájlról, amelyet az adott munkamenetben szerkesztett. A pillanatképek a ~/.claude/file-history/{sessionId}/ mappában tárolódnak, legfeljebb 30 napig. A pillanatképek inkrementálisak—csak az állapotok közötti különbségek mentődnek el, nem a teljes fájl. Alapértelmezés szerint munkamenetenként legfeljebb 100 pillanatkép tárolódik. Ez azt jelenti, hogy a legtöbb valós projektben bármikor rendelkezésedre áll az egész munkanap során Claude által végzett összes módosítás teljes előzménye.

A visszatekerési menü megnyitásához nyomd meg kétszer az Esc billentyűt, amikor a beviteli mező üres:

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

Ha van szöveg a beviteli mezőben, az Esc első dupla lenyomása törli, és elmenti az Up előzmények közé. Ez akkor hasznos, ha már elkezdtél gépelni, majd rájössz, hogy vissza kell tekerned. Íme egy idézet az Anthropic hivatalos dokumentációjából:

A /rewind parancs ugyanezt teszi—megnyitja a menüt. Van egy aliasa, a /checkpoint, amely ugyanoda vezet. Hogy melyik módszer kényelmesebb, megszokás kérdése. Én az Esc Esc kombinációt használom—gyorsabb, és nem kell levennem a kezemet a billentyűzetről.

A Rewind menü 6 módja: melyiket válaszd, és mikor?#

Válassz ki egy pontot a listából, és megjelenik a műveletek menüje. Hat eleme van, mindegyik mást csinál.

A módok teljes táblázata:

A Summarize up to here funkció a 2026. május 11–15. között, a 20. héten kiadott Claude Code v2.1.139-v2.1.142 verzióban jelent meg:

A Restore és a Summarize közötti különbség alapvető. A Restore visszatér egy korábbi állapothoz, és visszavon mindent, ami a kiválasztott pont után történt. A Summarize semmit sem von vissza; csak tömörít—az eredeti üzenetek a munkamenet átiratában megmaradnak referenciaként, de az aktív kontextusban csak az összefoglaló marad. Akkor használd a restore-t, ha azt szeretnéd, hogy „mintha ez meg sem történt volna”. A summarize-t akkor használd, ha „meg akarod tartani, de nem akarod, hogy helyet foglaljon a kontextusban”.

A Restore conversation vagy a Summarize from here után a kiválasztott prompt eredeti szövege visszakerül a beviteli mezőbe—szerkesztheted és újra elküldheted. A Summarize up to here után a beviteli mező üres, és a beszélgetés végén maradsz.

Milyen változtatásokat NEM von vissza a /rewind?#

Ez az a fő korlátozás, amibe az emberek beleütköznek: a /rewind zöld pipát mutat, és azt írja, hogy „a visszatekerés sikeres”, a projekt mégis hibás, mert Claude nem csak fájlokat módosított. Nézzük meg a három esetet.

1. A bash-parancsok nem követhetők. Ha Claude egy fordulóban lefuttatja a rm file.txt vagy mv old.txt new.txt parancsot, ezek a módosítások nem kerülnek be a checkpointba. Az Anthropic dokumentációja ezt kifejezetten kimondja:

Ez azt jelenti, hogy ha Claude a bash eszközzel önállóan töröl, áthelyez vagy másol egy fájlt, a /rewind nem fog mindent helyreállítani. A git checkout vagy egy biztonsági mentésből történő visszaállítás segíthet, de ehhez több kell két billentyű lenyomásánál.

2. A külső szerkesztéseket nem érzékeli. Ha kézzel megnyitsz és szerkesztesz egy fájlt a VS Code-ban, vagy egy második Claude-munkamenet párhuzamosan módosítja ugyanazokat a fájlokat, az első munkamenet nem látja ezeket a változtatásokat. A checkpoint pillanatképe akkor készül, amikor Claude befejez egy fordulót az aktuális munkamenetben. Ami a fordulók között történik, az kívül esik a felelősségén.

3. A fájlokon kívüli műveletekre egyáltalán nem terjed ki. Egy npx prisma migrate dev paranccsal alkalmazott Prisma-migráció megváltoztatta az adatbázis sémáját—ezt a /rewind nem vonja vissza, mert az adatbázis a projekt fájlrendszerén kívül van. A origin/main ágra végzett force-push ugyanez: a commit felkerült a távoli szerverre, a checkpoint pedig nem hozza vissza. Egy távoli API-hívás, amely pénzt vont le vagy törölt egy rekordot, csak az API saját mechanizmusaival vonható vissza.

Szabály: Ha egy feladat a projektfájlokon kívül bármit érint—adatbázis-migrációkat, git push műveletet vagy távoli API-kat—készíts külön visszaállítási tervet minden egyes külső hatáshoz. A /rewind csak az aktuális munkamenet helyi fájlelőzménye.

/rewind és git: miben különböznek, és miért van szükség mindkettőre?#

Az Anthropic dokumentációja közvetlenül megfogalmazza ezt a párosítást:

A különbségek egyetlen táblázatban:

A párosítás egyszerű: valahányszor eljutsz egy olyan állapothoz, ahol „ez működik, és nem akarom elveszíteni”, készíts git commit-ot. A commitok között hagyatkozz a /rewind-ra—azonnali, nem kell hozzá commitüzenet, és nem zsúfolja tele a git előzményeit köztes állapotokkal. A munka végén commitolj—lehetőleg értelmes, atomi commitot.

Miért nem fedi le egyetlen /rewind az egész feladatot?#

A visszavonás a kontextusmérnökség egyik esete. Ha kezeled a munkamenet kontextusát (mikor commitolj, mikor nyomd meg a /rewind billentyűkombinációt, milyen szabályokat tegyél a CLAUDE.md fájlba), kiszámítható Claude-ot kapsz, amely nem teszi tönkre a projektet vagy veszíti el a munkát.

Miért veszélyes a git reset --hard, ha „visszaállítást” kérsz Claude-tól?#

A „mentsd el az aktuális állapotot, és térj vissza az utolsó push állapotára” kérés ezekhez a parancsokhoz vezethet:

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

Az első parancs helyes volt—elmentette a nem commitolt módosításokat a stashbe. A második romboló volt: a 35eb731 commitra írta át az ágat, így az ez és a 882e618 közötti összes commit árvává vált. Alapértelmezés szerint az árva commitok a .git/objects/ mappában maradnak a git gc lefutásáig, ami rendszerint két héten belül automatikusan megtörténik. De ha akkor nem tudtad, mit kell tenni, már fogyott az időd.

A logika egyszerű: a természetes nyelvben a „visszaállítás”, „visszalépés”, „helyreállítás”, „visszafordítás” és „visszavonás” azt jelenti, hogy „nézd meg a korábbi állapotot” vagy „térj vissza egy biztonságos helyre”. Nem azt jelentik, hogy „semmisítsd meg az előzményeket”. A git reset --hard parancs megsemmisíti az előzményeket—átírja az ágat, és eltávolítja azokat a commitokat, amelyek a HEAD-en keresztül elérhetők. Biztonságos alternatíva a git checkout <commit>, amely detached HEAD-et hoz létre, és lehetővé teszi a régi állapot megtekintését az ágak érintése nélkül.

A legfontosabb gyakorlati tanulság az, hogy minden jelentősebb feladat előtt commitold az aktuális állapotot, különösen több fájlt érintő refaktorálás előtt. Egyetlen commit révén Claude bármilyen hibája egy git checkout . paranccsal orvosolható, munka elvesztése nélkül.

Hogyan ment meg a git reflog egy romboló reset után?#

Romboló reset után azonnal futtasd le a git reflog parancsot:

git reflog

A kimenet így néz ki:

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

A HEAD@{1} és a HEAD@{3} közötti bejegyzések éppen azok a „megsemmisített” commitok. Nem tűntek el a git helyi objektumtárolójából; csupán az ágon keresztül váltak elérhetetlenné. A helyreállításukhoz:

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

# Or switch directly
git reset --hard 882e618

Ezután az ág ismét tartalmazza a katasztrófáig vezető teljes előzményt.

A Reflog korlátai:

1. Csak helyi. A reflog a .git/logs/HEAD fájlban tárolódik; a távoli tárolóban nincs ott. Ha force-push-t hajtasz végre, majd törlöd a helyi tároló példányát, a reflog is eltűnik a mappával együtt.
2. Alapértelmezés szerint 90 napig él. A régebbi bejegyzéseket a git gc eltávolíthatja. A beállítás a git config gc.reflogExpire 200.days.ago paranccsal módosítható.
3. Arra nem terjed ki, ami sosem volt a HEAD-ben. Ha egy commit csak a stashben volt, és a stash megsemmisült, a reflog csak a stash legutóbbi állapotát mutatja, a belső előzményeit nem.

Csapatszabály: katasztrófa után soha ne futtasd azonnal a git gc --aggressive parancsot. Először vizsgálódj a reflog segítségével, és állítsd helyre az adatokat; csak ezután végezd el a többi műveletet. És soha ne töröld a helyi tárolóklónt, amíg nem vagy biztos benne, hogy minden szükségeset feltoltál.

Hogyan védd meg a projektet a romboló git-parancsoktól a CLAUDE.md segítségével?#

A sérülékenység az, hogy Claude alapértelmezés szerint nem rendelkezik védelmi kontextussal. A „visszaállítás” kérést git reset --hard parancsként értelmezi, mert technikailag ez egy érvényes módszer. Helyezd el a védelmet a CLAUDE.md fájlban—a projekt rendszerpromptfájljában.

Minimális szabály (illeszd be a CLAUDE.md fájlba):

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

Kibővített csapatszabály (add hozzá a tároló gyökerében lévő CLAUDE.md fájlhoz):

## Git Workflow Rules

- Minden működő mérföldkőnél készíts commitot. WIP-commit előtt futtasd a `git status` és `git diff` parancsot, csak a kifejezetten átnézett, név szerint megadott fájlokat vedd fel a `git add -- path/to/file` paranccsal, majd commit előtt nézd át az index diffjét. Az időzítő felülvizsgálati emlékeztető, nem engedély a teljes munkafa felvételére.
- 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.

A blokkok hozzáadása után a következő „állítsd vissza az utolsó push állapotára” kérés ilyen választ eredményezne:

3 nem commitolt fájlt látok, és 4 commit van az utolsó push után. Két lehetőség van:

1. BIZTONSÁGOS: létrehozok egy view-last-push ágat a git checkout <last-push-hash> paranccsal—megőrzöm az összes munkát, de ideiglenesen megmutatom a push állapotát.
2. ROMBOLÓ: git reset --hard <last-push-hash>—véglegesen megsemmisítek 4 commitot és a nem commitolt módosításokat. Ezek csak a git reflog segítségével állíthatók vissza 90 napon belül. Melyiket választod?

Ez fél perc beszélgetés, nem négy óra elvesztett munka.

Mi az 5 módszer a Claude Code-ban történő visszavonásra, és hogyan válaszd ki a megfelelőt?#

A „Claude elrontotta, sürgősen vissza kell állítanom” helyzetben ezen a létrán alulról felfelé haladj. Mindig az 1. szinten kezdd.

1. szint. /rewind—azonnali visszavonás egy munkameneten belül.

Nyomd meg az Esc Esc billentyűkombinációt, vagy írd be, hogy /rewind. Válaszd ki a hiba előtti pontot. Válassz egy módot (általában Restore code and conversation). Egy másodperccel később már a múltban vagy, és kezdheted elölről. Az olyan esetek 80%-át lefedi, amikor „Claude rossz dolgot csinált”.

2. szint. git checkout .—az összes nem commitolt módosítás visszavonása.

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

Akkor hasznos, ha a /rewind nem működött (például Claude bash-en keresztül módosított fájlokat), vagy a munkamenet előzményein kívüli módosításokat kell visszavonnod. Minden nem commitolt módosítás véglegesen eltűnik. Ha ezt esetleg megbánnád, előbb futtasd a git stash parancsot (lásd a 2.5. szintet).

2.5. szint. git stash—tedd félre a módosításaidat.

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

Jó kompromisszum a „vesszen örökre” és a „maradjon így” között. A stash helyben megmarad, amíg kifejezetten nem törlöd.

3. szint. git checkout <commit>—visszatérés egy régi commitra az előzmények elvesztése nélkül.

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

Ez egy biztonságos „ideiglenes visszatérés”. A detached HEAD nem módosítja az ágat; a main ágon (vagy azon, amelyiken éppen voltál) végzett jelenlegi munkád érintetlen marad. Ha dolgozni szeretnél ebben az állapotban, hozz létre egy ágat.

4. szint. git reset --hard <commit>—az ág visszaállítása egy adott pontra.

⚠️ Romboló. A megadott hash-nél újabb commitok árvává válnak.

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

Csak akkor használd, ha biztos vagy benne, hogy nincs szükséged az ennél újabb commitokra. És reset előtt mindig ellenőrizd a git reflog kimenetét, hogy tudd, hová térhetsz vissza, ha meggondolod magad.

5. szint. git reflog + helyreállítás—katasztrófahelyzet.

Valaki (Claude, te vagy egy kollégád) már lefuttatta a git reset --hard parancsot vagy force-push-t végzett, és eltüntette a munkát. Mit kell tenni?

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

Ha a reflogot már törölték (alapértelmezés szerint 90 nap után), az utolsó lehetőség a git fsck --lost-found, amely megmutatja a .git/objects/ mappában lévő lógó commitokat. Ez már-már régészet, de néha működik.

Szabály a megfelelő szint kiválasztásához:

Hogyan védd meg a projektet, hogy ne legyen mit visszavonni?#

1. szabály. Commitolj 30 percenként.

Ne várd meg, amíg „elkészül a feladat”. Commitolj minden működő köztes lépést. A commitüzenet bármi lehet; a lényeg, hogy Claude (vagy te) egyetlen git checkout paranccsal visszatérhessen egy működő állapothoz.

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

Ha PostToolUse emlékeztetőt adsz hozzá, tartsd meg ugyanazt az átnézési és kifejezett útvonalas felvételi szabályt. Az időzítőből ne legyen ellenőrizetlen automatikus commit: különben idegen módosítások vagy már indexbe tett fájlok is belekerülhetnek.

2. szabály. Minimális .gitignore.

A következő soroknak szerepelniük kell a projekt gyökérkönyvtárában:

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

A .claude/personal/ mappát saját kísérleteimhez és jegyzeteimhez használom; ezek nem kerülhetnek be a megosztott tárolóba. A .claude/sessions/ és a .claude/file-history/ mappa a Claude Code helyi tárolója; nincs helyük a tárolóban, sok helyet foglalnak, és egy adott géphez kötődnek.

3. szabály. Kísérletezz külön ágon.

Ha nagy a feladat (10+ fájl refaktorálása, átállás új adatbázisra, egy modul újraírása), ne a főágon dolgozz:

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

Ez az egyszerű szokás a „Claude tönkretette a projektet” helyzetet erre változtatja: „Claude tönkretett egy ágat, töröltem, és kezdhetjük elölről.”

4. szabály. Veszélyes műveletek előtt használd a git tag parancsot.

Adatbázis-migráció, nagy refaktor vagy függőségfrissítés előtt hozz létre egy taget:

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

A tag egy commit elnevezett mutatója, amelyet a reflog tisztítása után sem veszítesz el.

Mi következik: hogyan illeszkedik a visszavonás a kontextusmérnökségbe?#

A visszavonás e három szintje egyetlen készség infrastruktúrája: annak tudásáé, hogyan állíts vissza egy állapotot, ha valami elromlik. Ez a készség önmagában szűk körű. Más kontextusmérnöki eszközökkel együtt azonban valami többre képes.

A Plan Mode nem engedi, hogy azonnal kódot írj—előbb terv készül, aztán jóváhagyás, majd végrehajtás. Ez a megelőző visszavonás: nem írsz meg olyasmit, amit később vissza kellene vonnod, mert a tervet előre átnézték. Bővebben a Plan Mode a Claude Code-ban című útmutatóban olvashatsz róla.

A CLAUDE.md olyan szabályokat határoz meg, amelyeket Claude alapértelmezés szerint tiszteletben tart, beleértve a fent bemutatott Git Safety Protocolt. Ez megelőző védelem a romboló parancsok ellen.

A Second Brain munkamenetek között is memóriát biztosít Claude-nak a projektről—tudja, milyen kódod van, mi az üzleti logika, és milyen megállapodások születtek korábban. Minél több a memória, annál kisebb az esélye, hogy rossz dolgot tesz.

A Skills és alügynökök jelentik a módszertanodat kódban. Ha a helyes git-munkafolyamat beépül egy Skillbe, egyetlen alügynök sem fog megerősítés nélkül git reset --hard parancsot futtatni.

Mindez együtt a Context Engineering. A prompt előtt kezeld a kontextust, ne közben. Bővebben itt olvashatsz róla: mi az a context engineering.

A visszavonás az utolsó védelmi vonal. A Plan Mode + CLAUDE.md + Second Brain + Skills az első négy. Ha ezek be vannak állítva, a visszavonás ritka és gyors. Ha nincsenek, mindennapos rutinná válik.

A visszavonás ott kezdődik, ahol a tervezés véget ér.

A Ailoot megnyitása.