Kaip atšaukti pakeitimus Claude Code: /rewind ir git

Praktinės informacijos apie darbą su Ailoot rasite dokumentacijoje.

Kas yra atšaukimas Claude Code ir kodėl neužtenka trijų lygių?#

Pirmąją Claude Code naudojimo savaitę įjungiau /rewind, kai įrankis dviem užklausomis sugadino projekto autentifikavimo logiką. Grąžinau ankstesnę būseną, lengviau atsikvėpiau ir tęsiau darbą. Po mėnesio nutiko kitaip: rašiau schemos migraciją, Claude padėjo, aš įrašiau pakeitimus, perėjau į kitą šaką ir supratau, kad pamiršau būtiną veiksmą. /rewind nepadėjo – sesija jau buvo kita. Padėjo git checkout į ankstesnį įrašą. Dar po mėnesio netyčia pasakiau agentui: „grąžink viską į paskutinį išsiuntimą“, ir jis paleido git reset --hard, sunaikindamas trijų valandų darbą. Mane išgelbėjo git reflog – sunaikintų įrašų maišos reikšmės vis dar buvo išsaugotos.

Šios trys istorijos atspindi tris apsaugos lygius, kurie veikia skirtingai, padeda aptikti skirtingas klaidas ir visi yra reikalingi. Šiame vadove paaiškinamas kiekvienas lygis, jo komandos, apribojimai ir pavyzdžiai. Taip pat parodoma, kaip iš anksto sukonfigūruoti projektą, kad Claude jo nesugadintų.

3 atšaukimo lygiai – kas ir kada:

Toliau aptarsime kiekvieną lygį – ką tiksliai daryti, kokių spąstų saugotis ir kaip viską sukonfigūruoti, kad nebūtų ko atšaukti, nes niekas nesugedo.

Kaip iškviesti /rewind: komanda ar Esc-Esc?#

Po kiekvieno atsakymo Claude automatiškai sukuria visų failų, kuriuos redagavo per tą sesiją, momentinę kopiją. Kopijos saugomos ~/.claude/file-history/{sessionId}/ ir išlaikomos iki 30 dienų. Jos yra prieauginės – išsaugomi tik būsenų skirtumai, o ne visas failas. Pagal numatytuosius nustatymus vienoje sesijoje saugoma iki 100 momentinių kopijų. Tai reiškia, kad daugumoje realių projektų bet kuriuo metu turite visą Claude pakeitimų per darbo dieną istoriją.

Norėdami atidaryti atšaukimo meniu, du kartus paspauskite Esc, kai įvesties laukas tuščias:

[įvesties laukas tuščias]
> _

[paspauskite Esc, Esc]

Į kurį pranešimą grąžinti?
  1. Sukurti User lentelės migraciją                 (pakeisti 3 failai)
  2. Pridėti lastLoginAt lauką                       (pakeistas 1 failas)
  3. Perrašyti autorizavimo logiką                  (pakeisti 5 failai)
  ...

Jei įvesties lauke yra teksto, pirmas dvigubas Esc paspaudimas jį išvalo ir išsaugo istorijoje, kurią galima pasiekti rodykle Up. Tai naudinga, kai jau pradėjote rašyti ir supratote, kad reikia grąžinti ankstesnę būseną. Citata iš oficialios Anthropic dokumentacijos:

Komanda /rewind atlieka tą patį – atidaro meniu. Yra ir pseudonimas /checkpoint, kuris veda į tą pačią vietą. Kurį būdą rinktis, priklauso nuo įpročio. Aš naudoju Esc Esc – taip greičiau ir nereikia atitraukti rankų nuo klaviatūros.

6 režimai meniu „Rewind“: kurį pasirinkti ir kada?#

Pasirinkite tašką sąraše ir pateksite į veiksmų meniu. Jame yra šeši elementai, kurių kiekvienas atlieka ką kita.

Visa režimų lentelė:

Funkcija Summarize up to here atsirado Claude Code v2.1.139-v2.1.142, išleistose 2026 m. gegužės 11–15 d., 20 savaitę:

Skirtumas tarp Restore ir Summarize yra esminis. „Restore“ grąžina ankstesnę būseną ir panaikina viską, kas įvyko po pasirinkto taško. „Summarize“ nieko neatšaukia – tik suglaudina: pradiniai pranešimai lieka sesijos išraše, kad būtų galima juos peržiūrėti, bet aktyviame kontekste lieka tik santrauka. Rinkitės atkūrimą, kai norite, kad būtų „taip, tarsi to niekada nebuvo“. Rinkitės santrauką, kai norite „tai išsaugoti, bet neužimti konteksto vietos“.

Po Restore conversation arba Summarize from here pasirinktos užklausos pradinis tekstas grąžinamas į įvesties lauką – galite jį redaguoti ir siųsti dar kartą. Po Summarize up to here įvesties laukas būna tuščias ir liekate pokalbio pabaigoje.

Kokių pakeitimų /rewind NEatšaukia?#

Tai pagrindinis apribojimas, su kuriuo susiduriama: /rewind parodo žalią varnelę ir praneša „atšaukimas sėkmingas“, tačiau projektas vis dar sugadintas, nes Claude pakeitė daugiau nei failus. Panagrinėkime tris atvejus.

1. Bash komandos nesekamos. Jei Claude per veiksmų seką paleidžia rm file.txt arba mv old.txt new.txt, šie pakeitimai nebus įtraukti į kontrolinį tašką. Anthropic dokumentacijoje aiškiai nurodyta:

Tai reiškia, kad jei Claude pats ištrina, perkelia ar nukopijuoja failą naudodamas bash įrankį, /rewind visko neatkurs. Gali padėti git checkout arba atkūrimas iš atsarginės kopijos, bet tam reikia daugiau nei dviejų klavišų paspaudimų.

2. Išoriniai redagavimai nepastebimi. Jei rankiniu būdu atidarote failą VS Code ir ką nors pakeičiate arba antra Claude sesija lygiagrečiai pakeičia tuos pačius failus, pirmoji sesija šių pakeitimų nemato. Kontrolinio taško momentinė kopija sukuriama Claude baigus veiksmų seką dabartinėje sesijoje. Tai, kas vyksta tarp veiksmų sekų, nepatenka į jo atsakomybę.

3. Operacijos už failų ribų visai neapimamos. Per npx prisma migrate dev pritaikius „Prisma“ migraciją, pasikeitė duomenų bazės schema – /rewind jos nepanaikins, nes duomenų bazė yra už projekto failų sistemos ribų. Priverstinis išsiuntimas į origin/main yra toks pat atvejis: įrašas pateko į nuotolinį serverį, o kontrolinis taškas jo negrąžins. Nuotolinės API užklausos, kuri nuskaičiavo pinigus arba ištrynė įrašą, pasekmes galima panaikinti tik naudojant pačios API mechanizmus.

Taisyklė: jei užduotis paveikia ką nors už projekto failų ribų – duomenų bazės migracijas, git push ar nuotolines API – parenkite atskirą kiekvieno išorinio poveikio atšaukimo strategiją. /rewind apima tik dabartinės sesijos vietinę failų istoriją.

/rewind ir git: kuo jie skiriasi ir kodėl reikia abiejų?#

Anthropic dokumentacijoje šis derinys aprašytas tiesiogiai:

Skirtumai vienoje lentelėje:

Derinys paprastas: kai tik pasiekiate būseną, kai „tai veikia ir nenoriu to prarasti“, sukurkite git commit. Tarp įrašų naudokite /rewind – jis veikia akimirksniu, nereikalauja įrašo pranešimo ir neapkrauna git istorijos tarpinėmis būsenomis. Baigę darbą sukurkite įrašą – geriausia prasmingą, atominį.

Kodėl vieno /rewind neužtenka visai užduočiai?#

Atšaukimas yra vienas konteksto inžinerijos atvejis. Valdykite sesijos kontekstą (kada įrašyti pakeitimus, kada spausti /rewind, kokias taisykles įrašyti į CLAUDE.md), ir Claude veiks nuspėjamai, nesugadins projekto ir nepraras darbo.

Kodėl git reset --hard pavojinga, kai prašote Claude „grįžti atgal“?#

Prašymas „išsaugoti dabartinę būseną ir grįžti į paskutinį išsiuntimą“ gali baigtis šiomis komandomis:

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

Pirmoji komanda buvo teisinga – ji išsaugojo neįrašytus pakeitimus „stash“ saugykloje. Antroji buvo destruktyvi: ji perrašė šaką į įrašą 35eb731, o visi įrašai tarp jo ir 882e618 tapo atskirtaisiais. Pagal numatytuosius nustatymus atskirtieji įrašai lieka .git/objects/ kataloge, kol paleidžiama git gc. Paprastai tai įvyksta automatiškai per dvi savaites. Tačiau jei tuo metu nežinojote, ką daryti, laikas jau veikė prieš jus.

Logika paprasta: natūralioje kalboje „grįžti atgal“, „sugrįžti“, „atkurti“, „anuliuoti“ ir „atšaukti“ reiškia „pažvelgti atgal“ arba „grįžti į saugią vietą“. Tai nereiškia „sunaikinti istoriją“. Komanda git reset --hard ją sunaikina – perrašo šaką ir pašalina įrašus iš pasiekiamų per HEAD. Saugi alternatyva yra git checkout <commit>: sukuriama atjungta HEAD būsena, kurioje galite peržiūrėti ankstesnę būseną neliesdami šakų.

Svarbiausia praktinė išvada – prieš bet kokią didesnę užduotį, ypač prieš kelių failų pertvarkymą, sukurti dabartinės būsenos git commit. Vienas įrašas reiškia, kad bet kokią Claude klaidą galima ištaisyti viena git checkout . komanda, neprarandant darbo.

Kaip git reflog išgelbėja po destruktyvaus atstatymo?#

Po destruktyvaus reset iškart paleiskite git reflog:

git reflog

Išvestis atrodo taip:

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}–HEAD@{3} yra būtent tie „sunaikinti“ įrašai. Jie nedingo iš vietinės git objektų saugyklos – tapo nepasiekiami per šaką. Norėdami juos atkurti:

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

# Or switch directly
git reset --hard 882e618

Po to šakoje vėl bus visa istorija iki katastrofos.

Reflog apribojimai:

1. Tik vietinis. Reflog saugomas .git/logs/HEAD faile; jo nėra nuotolinėje saugykloje. Jei priverstinai išsiunčiate pakeitimus, o tada ištrinate vietinę saugyklos kopiją, reflog dingsta kartu su aplanku.
2. Pagal numatytuosius nustatymus – 90 dienų. Senesni įrašai gali būti pašalinti paleidus git gc. Šį laikotarpį galite konfigūruoti naudodami git config gc.reflogExpire 200.days.ago.
3. Neapima to, kas niekada nebuvo HEAD. Jei įrašas buvo tik „stash“ saugykloje, o „stash“ buvo sunaikintas, reflog rodys tik naujausią „stash“ būseną, o ne jo vidinę istoriją.

Taisyklė komandai: po katastrofos niekada iškart nepaleiskite git gc --aggressive. Pirmiausia ištirkite situaciją naudodami reflog ir atkurkite duomenis; visa kita darykite vėliau. Taip pat neištrinkite vietinio saugyklos klono, kol neįsitikinsite, kad viskas, ko reikia, buvo išsiųsta.

Kaip apsaugoti projektą nuo destruktyvių git komandų naudojant CLAUDE.md?#

Problema ta, kad Claude pagal numatytuosius nustatymus neturi apsauginio konteksto. Jis interpretuoja „grįžti atgal“ kaip git reset --hard, nes techniškai tai tinkamas metodas. Įrašykite apsaugą į CLAUDE.md – projekto sistemos raginimo failą.

Minimali taisyklė (įterpkite į savo CLAUDE.md):

## Git Safety Protocol

- Niekada nevykdyk destruktyvių git komandų (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), nebent aiškiai prašau atlikti šiuos veiksmus. Neteisėti destruktyvūs veiksmai nepadeda ir gali lemti darbo praradimą.
- Kai sakau „grįžti atgal“, „sugrįžti“, „atkurti“, „anuliuoti“ ar „atšaukti“, interpretuok tai kaip PERŽIŪROS komandas: naudok `git log`, `git diff`, `git checkout <commit>` (sukuria atjungtą HEAD būseną) arba `git stash` (išsaugo pakeitimus).
- VISADA paprašyk patvirtinimo prieš BET KURIĄ komandą, kuri:
  - Pakeičia HEAD padėtį į kitą įrašą šakoje
  - Keičia įrašų istoriją
  - Gali prarasti neįrašytą darbą
  - Apima vėliavėles --hard, --force, --aggressive
- Prieš bet kokią destruktyvią komandą pateik sunumeruotą palyginimą:
  - SAUGU: naudoti `git checkout <commit>` laikinai peržiūrai
  - DESTRUKTYVU: naudoti `git reset --hard` negrįžtamam sunaikinimui
- Prieš vykdydamas palauk, kol aiškiai pasirinksiu.

Išplėstinė taisyklė komandai (pridėkite prie saugyklos šakninio katalogo CLAUDE.md):

## Git Workflow Rules

- Įrašyk pakeitimus kiekviename veikiančiame etape. Prieš WIP įrašą paleisk `git status` ir `git diff`, paruošk tik aiškiai peržiūrėtus įvardytus failus su `git add -- path/to/file`, tada prieš įrašydamas patikrink paruoštų pakeitimų skirtumus. Laikmatis primena peržiūrėti, bet nesuteikia leidimo paruošti visą darbo medį.
- Niekada nenaudok `git add .` ar `git add -A` Claude įrašams. Nurodyk tik failus pagal pavadinimą, po `git status` + `git diff`.
- Prieš `git push --force` į main sustok ir paklausk manęs. Funkcijų šakose priverstinį išsiuntimą naudok atsargiai ir tik įsitikinęs, kad sutinku prarasti ankstesnę versiją.
- Spręsdamas sujungimo konfliktus, iškart nesirink „ours“ arba „theirs“ – pirmiausia parodyk man abi versijas, tada nuspręsiu.
- `.gitignore` faile turi būti `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. Jei jų nėra, pridėk.

Pridėjus šiuos blokus, į frazę „grįžti į paskutinį išsiuntimą“ būtų atsakyta taip:

Matau 3 neįrašytus failus ir 4 įrašus nuo paskutinio išsiuntimo. Galimi du variantai:

1. SAUGU: sukurti view-last-push šaką per git checkout <last-push-hash> – išsaugosiu visą darbą, bet laikinai parodysiu išsiųstą būseną.
2. DESTRUKTYVU: git reset --hard <last-push-hash> – negrįžtamai sunaikinsiu 4 įrašus ir neįrašytus pakeitimus. Juos bus galima atkurti tik per git reflog per 90 dienų. Kurį variantą pasirinksite?

Tai pusė minutės pokalbio vietoj keturių prarasto darbo valandų.

Kokie yra 5 atšaukimo būdai Claude Code ir kaip išsirinkti tinkamą?#

Scenarijuje „Claude kažką sugadino, reikia skubiai atkurti“ šia seka kylama nuo žemiausio lygio. Visada pradėkite nuo 1 lygio.

1 lygis. /rewind – momentinis atšaukimas sesijoje.

Paspauskite Esc Esc arba įrašykite /rewind. Pasirinkite tašką prieš klaidą. Pasirinkite režimą (paprastai Restore code and conversation). Po sekundės būsite grąžinti į ankstesnę būseną ir galėsite pradėti iš naujo. Tinka 80% atvejų, kai „Claude padarė ne taip“.

2 lygis. git checkout . – visų neįrašytų pakeitimų atšaukimas.

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

Naudinga, kai /rewind nepadėjo (pavyzdžiui, Claude keitė failus per bash) arba reikia anuliuoti veiksmus už sesijos istorijos ribų. Visi neįrašyti pakeitimai dings visam laikui. Jei galite dėl to apsigalvoti, pirmiausia paleiskite git stash (žr. 2,5 lygį).

2,5 lygis. git stash – padėkite pakeitimus į šalį.

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

Geras kompromisas tarp „prarasti visam laikui“ ir „palikti kaip yra“. „Stash“ lieka vietinis, kol aiškiai jo neišvalote.

3 lygis. git checkout <commit> – grįžkite į seną įrašą neprarasdami istorijos.

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

Tai saugus „laikinas grįžimas“. Atjungta HEAD būsena nepakeičia šakos; dabartinis jūsų darbas main (arba kitoje šakoje) lieka nepaliestas. Jei norite dirbti su šia būsena, sukurkite šaką.

4 lygis. git reset --hard <commit> – grąžinkite šaką į ankstesnį tašką.

⚠️ Destruktyvu. Nurodytą maišos reikšmę lenkiantys įrašai tampa atskirtaisiais.

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

Naudokite tik įsitikinę, kad jums nereikia vėlesnių įrašų. Ir prieš nustatydami būtinai patikrinkite git reflog, kad žinotumėte, kur grįžti, jei persigalvosite.

5 lygis. git reflog + atkūrimas – katastrofinis scenarijus.

Kažkas (Claude, jūs ar kolega) jau paleido git reset --hard arba priverstinį išsiuntimą ir sunaikino darbą. Ką daryti?

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

Jei reflog jau išvalytas (pagal numatytuosius nustatymus po 90 dienų), paskutinė išeitis yra git fsck --lost-found, kuri parodys paliktus įrašus .git/objects/ kataloge. Tai beveik archeologija, bet kartais padeda.

Kaip pasirinkti lygį:

Kaip apsaugoti projektą, kad nebūtų ko atšaukti?#

1 taisyklė. Kas 30 minučių peržiūrėkite pažangą ir įrašykite veikiantį etapą.

Nelaukite, kol „užduotis bus atlikta“. Įrašykite kiekvieną veikiantį tarpinį etapą. Įrašų pranešimai gali būti bet kokie; svarbiausia, kad Claude (arba jūs) galėtumėte viena git checkout komanda grįžti į veikiančią būseną.

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

Jei pridėsite PostToolUse priminimą, išlaikykite tą pačią peržiūros ir aiškių failų kelių paruošimo taisyklę. Nepaverskite laikmačio nepatikrintu automatiniu įrašymu: kitaip į įrašą gali patekti nesusiję pakeitimai ar jau paruošti failai.

2 taisyklė. Minimalus .gitignore.

Šios eilutės privalomos projekto šaknyje:

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

Aplanką .claude/personal/ naudoju savo bandymams ir užrašams, kurie neturi patekti į bendrinamą saugyklą. .claude/sessions/ ir .claude/file-history/ yra vietinė Claude Code saugykla; jie nepriklauso saugyklai, užima daug vietos ir yra susieti su konkrečiu kompiuteriu.

3 taisyklė. Bandymus atlikite atskiroje šakoje.

Jei užduotis didelė (pertvarkote 10+ failų, pereinate prie naujos duomenų bazės arba perrašote modulį), nedirbkite pagrindinėje šakoje:

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

Šis paprastas įprotis „Claude sugriovė projektą“ paverčia į „Claude sugriovė vieną šaką, ją ištryniau ir pradedame iš naujo“.

4 taisyklė. Prieš pavojingus veiksmus naudokite git tag.

Prieš duomenų bazės migraciją, didelį pertvarkymą ar priklausomybių atnaujinimą sukurkite žymą:

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

Žyma yra pavadinta įrašo nuoroda, kurios neprarasite net išvalius reflog.

Kas toliau: kaip atšaukimas siejasi su konteksto inžinerija?#

Šie trys atšaukimo lygiai yra vieno įgūdžio infrastruktūra: žinoti, kaip atkurti būseną, kai kas nors sugenda. Pats šis įgūdis yra siauras. Tačiau sujungtas su kitais konteksto inžinerijos įrankiais jis tampa kur kas svarbesnis.

Plan Mode neleidžia iškart rašyti kodo – pirmiausia parengiamas planas, tada gaunamas patvirtinimas ir tik tuomet vykdomas. Tai prevencinis atšaukimas: nerašote to, ką vėliau reikėtų atšaukti, nes planas buvo iš anksto peržiūrėtas. Daugiau skaitykite vadove apie Plan Mode Claude Code.

CLAUDE.md nustato taisykles, kurių Claude laikosi pagal numatytuosius nustatymus, įskaitant pirmiau aptartą Git saugos protokolą. Tai prevencinė apsauga nuo destruktyvių komandų.

Second Brain suteikia Claude atmintį apie projektą tarp sesijų – jis žino, kokį kodą turite, kokia yra verslo logika ir dėl ko susitarta anksčiau. Kuo daugiau atminties, tuo mažesnė tikimybė, kad jis pasielgs netinkamai.

Skills ir subagentai – tai jūsų metodika kode. Jei teisinga git darbo eiga įtraukta į „Skill“, nė vienas subagentas nepaleis git reset --hard be patvirtinimo.

Visa tai kartu yra Context Engineering. Valdykite kontekstą prieš pateikdami užklausą, o ne jos metu. Daugiau skaitykite straipsnyje kas yra konteksto inžinerija.

Atšaukimas – paskutinė gynybos linija. Plan Mode + CLAUDE.md + Second Brain + Skills yra pirmosios keturios. Kai jos parengtos, atšaukimo prireikia retai ir jis atliekamas greitai. Kai jų nėra, atšaukinėti tenka kasdien.

Atšaukimas prasideda ten, kur baigiasi planavimas.

Atidarykite Ailoot.