Ako vrátiť zmeny v Claude Code: /rewind a git

Praktické informácie o práci s Ailootom nájdete v dokumentácii.

Čo je vrátenie zmien v Claude Code a prečo nestačia tri úrovne?#

/rewind som zapol počas prvého týždňa používania Claude Code, keď mi v dvoch promptoch pokazil logiku autentifikácie projektu. Vrátil som zmeny, vydýchol si a pokračoval. O mesiac neskôr nastala ďalšia situácia: písal som migráciu schémy, Claude mi pomáhal, urobil som commit, prepol vetvu—a uvedomil som si, že som zabudol na potrebný krok. /rewind nepomohol—relácia už bola iná. Pomohol git checkout na predchádzajúci commit. O mesiac neskôr som agentovi omylom povedal: „vráť všetko do stavu posledného pushu“ a on spustil git reset --hard, čím zničil tri hodiny práce. Zachránil ma git reflog—hashe zničených commitov tam stále boli.

Tieto tri príbehy predstavujú tri úrovne ochrany, ktoré fungujú odlišne, zachytávajú rôzne chyby a sú potrebné všetky. Tento sprievodca vysvetľuje každú úroveň, jej príkazy, obmedzenia a príklady. Ukazuje tiež, ako projekt vopred nastaviť, aby ho Claude hneď na začiatku nezničil.

3 úrovne vrátenia zmien—čo a kedy:

Ďalej si prejdeme každú úroveň—čo presne treba urobiť, na aké pasce si dať pozor a ako všetko nastaviť tak, aby nebolo čo vracať, pretože sa nič nepokazilo.

Ako spustiť /rewind: príkazom alebo Esc-Esc?#

Po každej odpovedi Claude automaticky vytvorí snímku všetkých súborov, ktoré v danej relácii upravil. Snímky sa ukladajú do ~/.claude/file-history/{sessionId}/ a uchovávajú sa až 30 dní. Sú prírastkové—ukladajú sa iba rozdiely medzi stavmi, nie celý súbor. Predvolene sa v každej relácii uchováva až 100 snímok. To znamená, že vo väčšine skutočných projektov máte kedykoľvek kompletnú históriu všetkých zmien Claude počas pracovného dňa.

Ak chcete otvoriť ponuku vrátenia zmien, dvakrát stlačte Esc, keď je vstupné pole prázdne:

[vstupné pole používateľa je prázdne]
> _

[stlačte Esc, Esc]

Ku ktorej správe sa chcete vrátiť?
  1. Vytvorenie migrácie pre tabuľku User          (zmenené 3 súbory)
  2. Pridanie poľa lastLoginAt                     (zmenený 1 súbor)
  3. Prepísanie logiky autorizácie                 (zmenených 5 súborov)
  ...

Ak je vo vstupnom poli text, prvé dvojité stlačenie Esc ho vymaže a uloží do histórie Up. Hodí sa to, keď ste už začali písať a uvedomíte si, že potrebujete vrátiť zmeny. Citát z oficiálnej dokumentácie Anthropic:

Príkaz /rewind robí to isté—otvorí ponuku. Existuje aj alias /checkpoint, ktorý vedie na to isté miesto. Ktorý spôsob je pohodlnejší, závisí od zvyku. Používam Esc Esc—je to rýchlejšie a nemusím dávať ruky z klávesnice.

6 režimov v ponuke Rewind: ktorý si vybrať a kedy?#

Vyberte bod v zozname a zobrazí sa ponuka akcií. Šesť položiek, každá robí niečo iné.

Úplná tabuľka režimov:

Funkcia Summarize up to here sa objavila v Claude Code v2.1.139-v2.1.142, vydaných 11.–15. mája 2026, v 20. týždni:

Rozdiel medzi Restore a Summarize je zásadný. Restore vráti predchádzajúci stav a zruší všetko, čo sa stalo po vybranom bode. Summarize nič nevracia späť; iba skracuje—pôvodné správy zostanú v prepise relácie na nahliadnutie, no v aktívnom kontexte zostane iba súhrn. Restore použite, keď chcete, aby to bolo „ako keby sa to nikdy nestalo“. Summarize použite, keď to chcete „zachovať, ale nezaberať tým miesto v kontexte“.

Po Restore conversation alebo Summarize from here sa pôvodný text vybraného promptu vráti do vstupného poľa—môžete ho upraviť a znova odoslať. Po Summarize up to here je vstupné pole prázdne a zostanete na konci konverzácie.

Ktoré zmeny /rewind NEVRÁTI?#

Toto je hlavné obmedzenie, na ktoré ľudia narážajú: /rewind zobrazí zelenú značku začiarknutia a oznámi „vrátenie zmien bolo úspešné“, ale projekt je stále pokazený, pretože Claude zasiahlo aj do iných vecí než len do súborov. Pozrime sa na tieto tri prípady.

1. Príkazy Bash sa nesledujú. Ak Claude v jednom ťahu spustí rm file.txt alebo mv old.txt new.txt, tieto zmeny sa do checkpointu nezahrnú. Dokumentácia Anthropic to výslovne uvádza:

To znamená, že ak Claude samo cez nástroj bash odstráni, presunie alebo skopíruje súbor, /rewind neobnoví všetko. Pomôcť môže git checkout alebo obnovenie zo zálohy, no vyžaduje si to viac než stlačenie dvoch klávesov.

2. Externé úpravy sa nezachytia. Ak súbor otvoríte vo VS Code a niečo v ňom ručne upravíte, alebo druhá relácia Claude paralelne zmení tie isté súbory, prvá relácia tieto zmeny neuvidí. Snímka checkpointu sa vytvorí, keď Claude dokončí ťah v aktuálnej relácii. Čokoľvek, čo sa stane medzi ťahmi, je mimo jeho zodpovednosti.

3. Operácie mimo súborov nie sú pokryté vôbec. Migrácia Prisma použitá cez npx prisma migrate dev zmenila schému databázy—/rewind ju nevráti, pretože databáza je mimo súborového systému projektu. To isté platí pre force-push do origin/main: commit sa dostal na vzdialený server a checkpoint ho neobnoví. Vzdialené volanie API, ktoré strhlo peniaze alebo odstránilo záznam, možno vrátiť iba pomocou vlastných mechanizmov daného API.

Pravidlo: Ak úloha ovplyvňuje čokoľvek mimo súborov projektu—migrácie databázy, git push, vzdialené API—pripravte samostatnú stratégiu vrátenia zmien pre každý externý účinok. /rewind je iba lokálna história súborov v aktuálnej relácii.

/rewind a git: aký je medzi nimi rozdiel a prečo potrebujete oboje?#

Dokumentácia Anthropic túto kombináciu uvádza priamo:

Rozdiely v jednej tabuľke:

Kombinácia je jednoduchá: vždy keď sa dostanete do stavu, v ktorom „toto funguje a nechcem o to prísť“, urobte git commit. Medzi commitmi sa spoliehajte na /rewind—je okamžitý, nevyžaduje správu commitu a nezapĺňa históriu gitu priebežnými stavmi. Po dokončení práce vytvorte commit—ideálne zmysluplný, atómový.

Prečo jedno /rewind nepokryje celú úlohu?#

Vrátenie zmien je jedným z prípadov inžinierstva kontextu. Spravujte kontext relácie (kedy vytvoriť commit, kedy stlačiť /rewind, aké pravidlá vložiť do CLAUDE.md) a získate predvídateľné Claude, ktoré nezničí projekt ani nestratí prácu.

Prečo je git reset --hard nebezpečný, keď požiadate Claude, aby sa „vrátilo späť“?#

Požiadavka „ulož aktuálny stav a vráť sa k poslednému pushu“ môže viesť k týmto príkazom:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # uložil nepodané zmeny
git reset --hard 35eb731                                                # zničil commity d63695e..882e618

Prvý príkaz bol správny—uložil nepodané zmeny do stash. Druhý bol deštruktívny: prepísal vetvu na commit 35eb731 a všetky commity medzi ním a 882e618 sa stali osirelými. Osirelé commity štandardne zostávajú v .git/objects/, kým sa nespustí git gc, čo sa zvyčajne stane automaticky do dvoch týždňov. Ak ste však v tej chvíli nevedeli, čo robiť, čas už pracoval proti vám.

Logika je jednoduchá: v bežnej reči „vráť sa“, „choď späť“, „obnov“, „vráť zmenu“ a „vráť späť“ znamenajú „pozri sa dozadu“ alebo „vráť sa na bezpečné miesto“. Neznamenajú „znič históriu“. Príkaz git reset --hard ju ničí—prepíše vetvu a odstráni commity spomedzi tých, ktoré sú dostupné cez HEAD. Bezpečnou alternatívou je git checkout <commit>, ktorý vytvorí detached HEAD a umožní vám pozrieť si starý stav bez zásahu do vetiev.

Hlavným praktickým ponaučením je vytvoriť git commit aktuálneho stavu pred každou väčšou úlohou, najmä pred refaktorovaním viacerých súborov. Jeden commit zmení každý prešľap Claude na jediný príkaz git checkout . bez straty práce.

Ako vás git reflog zachráni po deštruktívnom resete?#

Po deštruktívnom resete hneď spustite git reflog:

git reflog

Výstup vyzerá takto:

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} až HEAD@{3} sú práve tie „zničené“ commity. Z lokálneho úložiska objektov git nezmizli; iba sa k nim už nedá dostať cez vetvu. Obnovíte ich takto:

# Vytvor vetvu z posledného „zničeného“ commitu
git branch recovered-work 882e618

# Alebo prepni priamo
git reset --hard 882e618

Potom vetva opäť obsahuje celú históriu až po katastrofu.

Obmedzenia Reflog:

1. Iba lokálne. Reflog sa ukladá do .git/logs/HEAD; nenachádza sa vo vzdialenom repozitári. Ak urobíte force-push a potom odstránite lokálnu kópiu repozitára, reflog zmizne spolu s priečinkom.
2. Predvolene 90 dní. Staršie položky môže odstrániť git gc. Nastaviť to môžete príkazom git config gc.reflogExpire 200.days.ago.
3. Nepokrýva to, čo nikdy nebolo v HEAD. Ak bol commit iba v stash a stash sa zničil, reflog zobrazí iba jeho posledný stav, nie vnútornú históriu.

Pravidlo pre tím: po katastrofe nikdy hneď nespúšťajte git gc --aggressive. Najprv všetko preskúmajte pomocou reflog a obnovte; ostatné riešte až potom. A nikdy nemažte lokálny klon repozitára, kým si nebudete istí, že všetko potrebné bolo odoslané.

Ako ochrániť projekt pred deštruktívnymi príkazmi git pomocou CLAUDE.md?#

Problém spočíva v tom, že Claude nemá predvolene žiadny ochranný kontext. Výraz „vráť sa“ interpretuje ako git reset --hard, pretože z technického hľadiska je to platná metóda. Ochranu vložte do CLAUDE.md—súboru systémového promptu projektu.

Minimálne pravidlo (vložte ho do svojho CLAUDE.md):

## Bezpečnostný protokol Git

- NIKDY nespúšťaj deštruktívne príkazy git (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), pokiaľ o tieto akcie výslovne nepožiadam. Neoprávnené deštruktívne akcie nepomáhajú a môžu spôsobiť stratu práce.
- Keď poviem "vráť sa", "choď späť", "obnov", "vráť zmenu", "vráť späť" - interpretuj to ako príkazy na PRESKÚMANIE: použi `git log`, `git diff`, `git checkout <commit>` (vytvorí detached HEAD) alebo `git stash` (zachová zmeny).
- VŽDY si vyžiadaj potvrdenie pred AKÝMKOĽVEK príkazom, ktorý:
  - Zmení pozíciu HEAD na iný commit vo vetve
  - Upraví históriu commitov
  - Môže spôsobiť stratu nepotvrdenej práce
  - Obsahuje príznaky --hard, --force, --aggressive
- Pred každým deštruktívnym príkazom zobraz očíslované porovnanie:
  - BEZPEČNÉ: použi `git checkout <commit>` na dočasné zobrazenie
  - DEŠTRUKTÍVNE: použi `git reset --hard` na trvalé zničenie
- Pred vykonaním počkaj na moju výslovnú voľbu.

Rozšírené pravidlo pre tím (pridajte ho do súboru CLAUDE.md v koreňovom priečinku repozitára):

## Pravidlá pracovného postupu Git

- Commit vytváraj pri každom funkčnom míľniku. Pred WIP commitom spusti `git status` a `git diff`, cez `git add -- path/to/file` priprav iba výslovne skontrolované pomenované súbory a pred commitom prezri pripravený diff. Časovač pripomína kontrolu, nepovoľuje pridať celý pracovný strom.
- Pri vytváraní commitov Claude nikdy nepoužívaj `git add .` ani `git add -A`. Po `git status` + `git diff` zadávaj iba názvy konkrétnych súborov.
- Pred `git push --force` do main—zastav sa a opýtaj sa ma. Vo vetvách funkcií používaj force-push opatrne, iba ak si si istý, že som ochotný prísť o predchádzajúcu verziu.
- Pri riešení konfliktov zlúčenia nikdy hneď nevyberaj "ours" ani "theirs"—najprv mi ukáž obe verzie a potom rozhodnem.
- `.gitignore` musí obsahovať `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. Ak chýbajú, pridaj ich.

Po pridaní týchto blokov by nasledujúca požiadavka „vráť sa k poslednému pushu“ viedla k takejto odpovedi:

Vidím 3 nepotvrdené súbory a 4 commity po poslednom pushi. Sú dve možnosti:

1. BEZPEČNÁ: vytvoriť vetvu view-last-push pomocou git checkout <last-push-hash>—zachovám všetku prácu, ale dočasne zobrazím stav posledného pushu.
2. DEŠTRUKTÍVNA: git reset --hard <last-push-hash>—natrvalo zničím 4 commity aj nepotvrdené zmeny. Obnoviť ich možno iba cez git reflog do 90 dní. Ktorú možnosť si vyberáš?

To je pol minúty konverzácie namiesto štyroch hodín stratenej práce.

Akých je 5 spôsobov vrátenia zmien v Claude Code a ako si vybrať ten správny?#

Scenár „Claude to pokazilo, potrebujem to okamžite obnoviť“ postupuje po tejto stupnici zdola nahor. Vždy začnite úrovňou 1.

Úroveň 1. /rewind—okamžité vrátenie zmien v rámci relácie.

Stlačte Esc Esc alebo zadajte /rewind. Vyberte bod pred chybou. Vyberte režim (zvyčajne Restore code and conversation). O sekundu ste späť v minulosti a môžete začať odznova. Pokrýva 80 % prípadov „Claude urobilo nesprávnu vec“.

Úroveň 2. git checkout .—vrátenie všetkých nepotvrdených zmien.

git diff                    # pozri sa najprv, čo sa skutočne zmenilo
git checkout .              # vráť späť všetky nepodané zmeny vo všetkých súboroch
# alebo selektívne:
git checkout -- path/to/file.ts   # iba jeden súbor

Užitočné, keď /rewind nefungoval (napríklad Claude zasiahlo do súborov cez bash) alebo keď potrebujete vrátiť zmeny mimo histórie relácie. Všetky nepotvrdené zmeny natrvalo zmiznú. Ak by ste to mohli oľutovať, najprv spustite git stash (pozri úroveň 2.5).

Úroveň 2.5. git stash—odložte zmeny bokom.

git stash save "možno to ešte budem potrebovať"
# návrat do čistého stavu (bez zmien)
# ...
# ak si to rozmyslíte—obnovte zo stash:
git stash pop

Dobrý kompromis medzi „navždy stratiť“ a „nechať tak“. Stash zostáva lokálny, kým ho výslovne nevymažete.

Úroveň 3. git checkout <commit>—návrat k starému commitu bez straty histórie.

git log --oneline               # nájdi hash správneho commitu, napr. abc1234
git checkout abc1234            # detached HEAD—zobrazenie bez zmeny
# ak sa ti stav páči, vytvor z neho vetvu:
git checkout -b recovery abc1234
# návrat:
git checkout main

Ide o bezpečný „dočasný návrat“. Detached HEAD nemení vetvu; vaša aktuálna práca vo vetve main (alebo vo vetve, v ktorej ste boli) zostáva nedotknutá. Ak chcete s týmto stavom pracovať, vytvorte vetvu.

Úroveň 4. git reset --hard <commit>—presunutie vetvy na určitý bod.

⚠️ Deštruktívne. Commity za uvedeným hashom sa stanú osirelými.

git reflog                                  # poznač si hash aktuálneho stavu
git reset --hard abc1234                    # prepíš vetvu
# našiel si chybu? vráť sa cez reflog:
git reset --hard HEAD@{1}                   # na miesto, kde si bol pred resetom

Použite iba vtedy, keď ste si istí, že commity za daným bodom nepotrebujete. A pred resetom vždy skontrolujte git reflog, aby ste vedeli, kam sa vrátiť, ak si to rozmyslíte.

Úroveň 5. git reflog + obnovenie—katastrofický scenár.

Niekto (Claude, vy, kolega) už spustil git reset --hard alebo force-push a zmazal prácu. Čo robiť?

git reflog                                          # hľadaj posledný hash pred katastrofou
git branch recovered HEAD@{N}                       # vytvor vetvu z neho
git checkout recovered                              # prepni sa na ňu
git diff main                                       # porovnaj s aktuálnym stavom
git checkout main && git merge recovered            # obnov do main, ak si si istý

Ak už bol reflog vymazaný (predvolene po 90 dňoch), poslednou možnosťou je git fsck --lost-found, ktorý zobrazí osirelé commity v .git/objects/. Je to takmer archeológia, ale niekedy to funguje.

Pravidlo výberu úrovne:

Ako zabezpečiť projekt, aby nebolo čo vracať?#

Pravidlo 1. Vytvorte commit každých 30 minút.

Nečakajte, kým bude „úloha hotová“. Vytvorte commit pre každý priebežný krok, ktorý funguje. Správy commitov môžu byť ľubovoľné; dôležité je, aby sa Claude (alebo vy) mohlo jedným príkazom git checkout vrátiť do funkčného stavu.

# na začiatku úlohy
git status                        # prezri všetky pripravené aj nepripravené cesty
git diff                          # skontroluj zmeny
# Túto ukážkovú cestu nahraď skutočným skontrolovaným súborom.
git add -- path/to/file.ts
git diff --cached                 # over presný obsah commitu
git commit -m "wip: starting User schema migration"

# po 30 minútach (alebo po prvej funkčnej iterácii)
git status
git diff
git add -- path/to/file.ts         # skutočná skontrolovaná cesta, nie zástupný celý priečinok
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# na konci úlohy—zmysluplný commit
git reset --soft HEAD~2           # spoj tri wip commity do jedného
git commit -m "feat(auth): add lastLoginAt field to User table"

Ak pridáte pripomienku PostToolUse, zachovajte kontrolu a pridávanie iba explicitných ciest. Časovač nemeňte na nekontrolovaný automatický commit: inak sa doň môžu dostať nesúvisiace úpravy alebo už pripravené súbory.

Pravidlo 2. Základný .gitignore.

V koreňovom priečinku projektu musia byť tieto riadky:

# tajné údaje
.env
.env.local
.env.*.local

# lokálne nastavenia Claude Code (neposielajú sa do tímového repozitára)
.claude/personal/
.claude/sessions/
.claude/file-history/

# závislosti a build
node_modules/
dist/
.next/
build/

Priečinok .claude/personal/ používam na vlastné experimenty a poznámky, ktoré nesmú byť zahrnuté v zdieľanom repozitári. Priečinky .claude/sessions/ a .claude/file-history/ sú lokálnym úložiskom Claude Code; do repozitára nepatria, zaberajú veľa miesta a viažu sa na konkrétny počítač.

Pravidlo 3. Experimenty na samostatnej vetve.

Ak je úloha rozsiahla (refaktorovanie 10+ súborov, migrácia na novú databázu, prepísanie modulu), nepracujte na hlavnej vetve:

git checkout -b experiment/auth-rewrite
# práca, commit každých 30 minút
# ak to funguje:
git checkout main
git merge experiment/auth-rewrite
# ak to nefunguje:
git checkout main
git branch -D experiment/auth-rewrite     # odstráň vetvu
# to je všetko, hlavná vetva zostáva nedotknutá

Tento jednoduchý zvyk mení „Claude zničilo projekt“ na „Claude zničilo jednu vetvu, vymazal som ju a začíname odznova“.

Pravidlo 4. Pred nebezpečnými operáciami použite git tag.

Pred migráciou databázy, veľkým refaktorovaním alebo aktualizáciou závislostí vytvorte tag:

git tag pre-prisma-migration-v2
# práca
# niečo sa pokazilo:
git reset --hard pre-prisma-migration-v2
# alebo sa len pozri:
git checkout pre-prisma-migration-v2

Tag je pomenovaný ukazovateľ na commit, ktorý nestratíte ani po vyčistení reflog.

Čo ďalej: ako súvisí vrátenie zmien s inžinierstvom kontextu?#

Tieto tri úrovne vrátenia zmien tvoria infraštruktúru jednej zručnosti: vedieť obnoviť stav, keď sa pokazí. Táto zručnosť je sama osebe úzko vymedzená. V kombinácii s ďalšími nástrojmi inžinierstva kontextu sa však mení na niečo viac.

Režim plánovania vám nedovolí hneď písať kód—najprv príde plán, potom potvrdenie a až potom vykonanie. Je to preventívne vrátenie zmien: nepíšete niečo, čo by ste neskôr museli vracať, pretože plán bol vopred skontrolovaný. Viac sa dočítate v sprievodcovi Režim plánovania v Claude Code.

CLAUDE.md stanovuje pravidlá, ktoré Claude štandardne rešpektuje, vrátane Protokolu bezpečnosti Git, o ktorom sme hovorili vyššie. Ide o preventívnu ochranu pred deštruktívnymi príkazmi.

Druhý mozog poskytuje Claude pamäť o projekte medzi reláciami—vie, aký kód máte, aká je obchodná logika a na čom ste sa dohodli predtým. Čím viac pamäte má, tým menšia je pravdepodobnosť, že urobí nesprávnu vec.

Skills a subagenti predstavujú vašu metodiku v kóde. Ak je správny pracovný postup git zabudovaný do Skill, žiadny subagent nespustí git reset --hard bez potvrdenia.

A to všetko spolu tvorí Inžinierstvo kontextu. Spravujte kontext pred promptom, nie počas neho. Viac sa dočítate v článku čo je inžinierstvo kontextu.

Vrátenie zmien je posledná obranná línia. Režim plánovania + CLAUDE.md + Druhý mozog + Skills sú prvé štyri. Keď sú nastavené, vrátenie zmien je zriedkavé a rýchle. Keď nastavené nie sú, stáva sa každodenným rituálom.

Vrátenie zmien sa začína tam, kde sa končí plánovanie.

Otvorte Ailoot.