Jak vrátit změny v Claude Code: /rewind a git

Praktické informace o práci s Ailootem najdete v dokumentaci.

Proč k vrácení změn Claude Code nestačí jeden postup?#

/rewind jsem si zapnul během prvního týdne používání Claude Code, když mi ve dvou zadáních rozbil logiku ověřování uživatelů v projektu. Vrátil jsem změny, vydechl si a pokračoval. O měsíc později nastala další situace: připravoval jsem migraci schématu, Claude mi pomohl, commitnul jsem ji, přepnul větev a uvědomil si, že jsem zapomněl na nezbytný krok. /rewind nepomohl – relace už byla jiná. Pomohl git checkout na předchozí commit. O měsíc později jsem agentovi omylem řekl: „vrať všechno k poslednímu pushi“, a on spustil git reset --hard, čímž zničil tři hodiny práce. Zachránil mě git reflog – hashe zničených commitů tam stále byly.

Tyto tři příběhy představují tři úrovně ochrany, které fungují odlišně, zachytávají různé chyby a všechny jsou potřeba. Tento návod vysvětluje každou úroveň, její příkazy, omezení a příklady. Ukazuje také, jak si projekt předem nastavit, aby ho Claude hned napoprvé nepoložil.

3 úrovně vrácení změn – co pokrývají a kdy:

Dále si projdeme každou úroveň – co přesně udělat, na co si dát pozor a jak vše nastavit tak, aby nebylo co vracet, protože se nic nerozbilo.

Jak v Claude Code spustit /rewind nebo použít Esc Esc?#

Po každé odpovědi Claude automaticky vytvoří snímek všech souborů, které v dané relaci upravil. Snímky se ukládají do ~/.claude/file-history/{sessionId}/ a uchovávají se až 30 dní. Jsou přírůstkové – ukládají se pouze rozdíly mezi stavy, nikoli celý soubor. Ve výchozím nastavení se pro každou relaci ukládá až 100 snímků. To znamená, že ve většině skutečných projektů máte v kterémkoli okamžiku k dispozici úplnou historii všech Claudeových změn během pracovního dne.

Nabídku návratu otevřete dvojitým stisknutím Esc, když je vstupní pole prázdné:

[vstupní pole je prázdné]
> _

[stiskněte Esc, Esc]

Ke které zprávě se chcete vrátit?
  1. Vytvořit migraci pro tabulku User             (změněny 3 soubory)
  2. Přidat pole lastLoginAt                       (změněn 1 soubor)
  3. Přepsat logiku autorizace                     (změněno 5 souborů)
  ...

Pokud je ve vstupním poli nějaký text, první dvojité stisknutí Esc ho smaže a uloží do historie Up. To se hodí, když už začnete psát a uvědomíte si, že se potřebujete vrátit. Citace z oficiální dokumentace Anthropic:

Příkaz /rewind udělá totéž – otevře nabídku. Existuje také alias /checkpoint, který vede na stejné místo. Volba pohodlnějšího způsobu závisí na zvyku. Používám Esc Esc – je to rychlejší a nemusím sundávat ruce z klávesnice.

6 režimů v nabídce Rewind: který zvolit a kdy?#

Vyberte bod v seznamu a dostanete se do nabídky akcí. Obsahuje šest položek, z nichž každá dělá něco jiného.

Úplná tabulka režimů:

Funkce Summarize up to here se objevila v Claude Code v2.1.139-v2.1.142, vydaném 11.–15. května 2026, ve 20. týdnu:

Rozdíl mezi Restore a Summarize je zásadní. Restore vrátí předchozí stav a zruší vše, co se stalo po vybraném bodu. Summarize nic nevrací, pouze komprimuje – původní zprávy zůstávají v přepisu relace k nahlédnutí, ale v aktivním kontextu zůstane pouze shrnutí. Restore použijte, když chcete, aby to bylo „jako by se to nikdy nestalo“. Summarize použijte, když chcete „si to nechat, ale nezabírat tím místo v kontextu“.

Po použití Restore conversation nebo Summarize from here se původní text vybraného zadání vrátí do vstupního pole – můžete ho upravit a znovu odeslat. Po použití Summarize up to here je vstupní pole prázdné a zůstáváte na konci konverzace.

Které změny /rewind NEVRÁTÍ?#

Tohle je hlavní omezení, na které lidé narazí: /rewind zobrazí zelenou fajfku a oznámí „návrat úspěšný“, ale projekt je stále rozbitý, protože Claude změnil víc než jen soubory. Podívejme se na tyto tři případy.

1. Bash příkazy se nesledují. Pokud Claude v některém tahu spustí rm file.txt nebo mv old.txt new.txt, tyto změny se do checkpointu nezahrnou. Dokumentace Anthropic výslovně uvádí:

Pokud tedy Claude soubor sám smaže, přesune nebo zkopíruje pomocí nástroje bash, /rewind neobnoví všechno. Pomůže git checkout nebo obnovení ze zálohy, ale vyžaduje to víc než stisknout dvě klávesy.

2. Externí úpravy se nezachytí. Pokud ručně otevřete soubor ve VS Code a něco v něm upravíte nebo druhá relace Claude souběžně změní stejné soubory, první relace tyto změny nevidí. Snímek checkpointu se pořídí, když Claude dokončí tah v aktuální relaci. To, co se děje mezi tahy, je mimo jeho odpovědnost.

3. Operace mimo soubory se nepokrývají vůbec. Migrace Prisma provedená příkazem npx prisma migrate dev změnila schéma databáze – /rewind ji nevrátí, protože databáze leží mimo souborový systém projektu. Totéž platí pro force-push do origin/main: commit se dostal na vzdálený server a checkpoint ho nevrátí. Vzdálené volání API, které strhlo peníze nebo smazalo záznam, lze vrátit pouze pomocí vlastních mechanismů daného API.

Pravidlo: Pokud úkol ovlivňuje něco mimo soubory projektu – migrace databáze, git push nebo vzdálená API –, připravte pro každý vnější dopad samostatný plán vrácení. /rewind je pouze lokální historie souborů v aktuální relaci.

/rewind a git: v čem se liší a proč potřebujete obojí?#

Dokumentace Anthropic toto propojení popisuje přímo:

Rozdíly shrnuje tabulka:

Je to jednoduché: kdykoli dosáhnete stavu, kdy „tohle funguje a nechci o to přijít“, vytvořte git commit. Mezi commity se spoléhejte na /rewind – je okamžitý, nevyžaduje zprávu commitu a nezanáší historii gitu mezistavy. Po dokončení práce vytvořte commit, nejlépe smysluplný a atomický.

Proč jeden /rewind nepokryje celý úkol?#

Vrácení změn je jedním z případů správy kontextu. Když řídíte kontext relace (kdy commitovat, kdy stisknout /rewind, jaká pravidla dát do CLAUDE.md), získáte předvídatelného Claudea, který nezničí projekt ani nepřijde o práci.

Proč je git reset --hard nebezpečný, když Claude požádáte, aby se „vrátil zpět“?#

Požadavek „ulož aktuální stav a vrať se k poslednímu pushi“ může vést k těmto příkazům:

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

První příkaz byl správný – uložil necommitnuté změny do stash. Druhý byl destruktivní: přepsal větev na commit 35eb731 a všechny commity mezi ním a 882e618 se staly osiřelými. Osiřelé commity ve výchozím nastavení zůstávají v .git/objects/, dokud se nespustí git gc, k čemuž obvykle automaticky dojde během dvou týdnů. Pokud ale v tu chvíli nevíte, co dělat, čas už hraje proti vám.

Logika je jednoduchá: výrazy v přirozeném jazyce jako „vrátit zpět“, „vrátit se“, „obnovit“, „revertovat“ a „vrátit změny“ znamenají „podívat se zpět“ nebo „vrátit se na bezpečné místo“. Neznamenají „zničit historii“. Příkaz git reset --hard historii ničí – přepisuje větev a odstraňuje commity z těch, na které lze dosáhnout přes HEAD. Bezpečnou alternativou je git checkout <commit>, který vytvoří oddělený HEAD a umožní vám prohlédnout si starý stav, aniž byste zasáhli do větví.

Hlavní praktické poučení: před každým větším úkolem, zejména před refaktoringem více souborů, vytvořte commit aktuálního stavu pomocí git commit. Jediný commit změní každý Claudeův průšvih na jeden příkaz git checkout ., aniž byste přišli o práci.

Jak vás git reflog zachrání po destruktivním resetu?#

Po destruktivním resetu hned spusťte git reflog:

git reflog

Výstup vypadá 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} jsou ony „zničené“ commity. Z místního úložiště objektů gitu nezmizely; pouze se k nim už nedá dostat přes větev. Obnovíte je takto:

# vytvoř větev z posledního „zničeného“ commitu
git branch recovered-work 882e618

# nebo přepni přímo
git reset --hard 882e618

Větev pak znovu obsahuje celou historii až po havárii.

Omezení reflogu:

1. Pouze místní. Reflog se ukládá do .git/logs/HEAD; ve vzdáleném repozitáři není. Když po force-pushi smažete místní kopii repozitáře, reflog zmizí spolu se složkou.
2. Ve výchozím nastavení 90 dní. Starší záznamy může odstranit git gc. Dobu můžete nastavit pomocí git config gc.reflogExpire 200.days.ago.
3. Nepokrývá to, co nikdy nebylo v HEAD. Pokud byl commit pouze ve stash a stash byl zničen, reflog zobrazí pouze poslední stav stash, nikoli jeho vnitřní historii.

Pravidlo pro tým: Po havárii nikdy hned nespouštějte git gc --aggressive. Nejprve vše prozkoumejte pomocí reflogu a obnovte stav; ostatní řešte až potom. A nikdy nemažte místní klon repozitáře, dokud si nejste jistí, že je vše potřebné odeslané.

Jak ochránit projekt před destruktivními příkazy git pomocí CLAUDE.md?#

Problém spočívá v tom, že Claude nemá ve výchozím nastavení žádný ochranný kontext. „Vrátit zpět“ vyhodnotí jako git reset --hard, protože z technického hlediska je to platná metoda. Ochranu vložte do souboru CLAUDE.md, který slouží jako systémový prompt projektu.

Minimální pravidlo (vložte do souboru CLAUDE.md):

## Protokol bezpečnosti gitu

- NIKDY nespouštěj destruktivní příkazy git (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), pokud o tyto akce výslovně nepožádám. Neoprávněné destruktivní akce nejsou užitečné a mohou vést ke ztrátě práce.
- Když řeknu „vrátit zpět“, „vrátit se“, „obnovit“, „revertovat“ nebo „vrátit změny“, chápej to jako pokyn k PROHLÉDNUTÍ historie: použij `git log`, `git diff`, `git checkout <commit>` (vytvoří oddělený HEAD) nebo `git stash` (zachová změny).
- VŽDY si vyžádej potvrzení před JAKÝMKOLI příkazem, který:
  - Změní pozici HEAD na jiný commit ve větvi
  - Upraví historii commitů
  - Může způsobit ztrátu necommitnuté práce
  - Obsahuje přepínače --hard, --force nebo --aggressive
- Před každým destruktivním příkazem vypiš číslované srovnání:
  - BEZPEČNÉ: použít `git checkout <commit>` pro dočasné zobrazení
  - DESTRUKTIVNÍ: použít `git reset --hard` pro trvalé zničení
- Před spuštěním počkej na můj výslovný výběr.

Rozšířené pravidlo pro tým (přidejte do souboru CLAUDE.md v kořeni repozitáře):

## Pravidla práce s Gitem

- Commituj každý funkční milník. Před WIP commitem spusť `git status` a `git diff`, přes `git add -- path/to/file` připrav jen výslovně prověřené soubory a před commitem prohlédni připravený diff. Časovač připomíná kontrolu; nepovoluje přípravu celého pracovního stromu.
- Při vytváření commitů Claudem nikdy nepoužívej `git add .` ani `git add -A`. Po `git status` a `git diff` výslovně uveď pouze konkrétní názvy souborů.
- Před `git push --force` do mainu se zastav a zeptej se mě. Ve feature větvích pushuj násilně opatrně, pouze pokud víš, že jsem ochoten přijít o předchozí verzi.
- Při řešení konfliktů při slučování nikdy hned nevybírej „ours“ nebo „theirs“ – nejprve mi ukaž obě verze a pak rozhodnu.
- Soubor `.gitignore` musí obsahovat `.env*`, `.claude/personal/`, `node_modules/` a `dist/`. Pokud v něm chybějí, přidej je.

Po přidání těchto bloků by fráze „vrať se k poslednímu pushi“ vedla k této odpovědi:

Vidím 3 necommitnuté soubory a 4 commity od posledního pushe. Máš dvě možnosti:

1. BEZPEČNÉ: vytvořit větev view-last-push přes git checkout <last-push-hash> – zachovám veškerou práci, ale dočasně zobrazím stav z posledního pushe.
2. DESTRUKTIVNÍ: git reset --hard <last-push-hash> – trvale zničím 4 commity a necommitnuté změny. Obnovit je lze pouze přes git reflog během 90 dní. Kterou možnost zvolíš?

To je půl minuty konverzace místo čtyř hodin ztracené práce.

Jakých je 5 způsobů vrácení změn v Claude Code a jak vybrat ten správný?#

Scénář „Claude to rozbil, musím to rychle obnovit“ řešte postupem odspodu po tomto žebříčku. Vždy začněte úrovní 1.

Úroveň 1. /rewind – okamžité vrácení změn v rámci relace.

Stiskněte Esc Esc nebo zadejte /rewind. Vyberte bod před chybou. Zvolte režim (obvykle Restore code and conversation). Za chvilku jste zpátky a můžete začít znovu. Pokrývá 80 % případů typu „Claude udělal něco špatně“.

Úroveň 2. git checkout . – vrácení všech necommitnutých změn.

git diff                    # nejprve zjisti, co se skutečně změnilo
git checkout .              # vrať všechny necommitnuté změny ve všech souborech
# nebo jen vybraný soubor:
git checkout -- path/to/file.ts   # pouze jeden soubor

Hodí se, když /rewind nefungoval (například Claude upravoval soubory přes bash) nebo potřebujete vrátit změny mimo historii relace. Všechny necommitnuté změny trvale zmizí. Pokud byste toho mohli litovat, nejprve spusťte git stash (viz úroveň 2.5).

Úroveň 2.5. git stash – odložení změn na polici.

git stash save "might still need this"
# vraťme se do čistého stavu (bez změn)
# ...
# když si to rozmyslíš, obnov změny ze stash:
git stash pop

Dobrý kompromis mezi „navždy ztratit“ a „nechat tak, jak to je“. Stash zůstane místní, dokud ho výslovně nesmažete.

Úroveň 3. git checkout <commit> – návrat ke starému commitu bez ztráty historie.

git log --oneline               # najdi hash správného commitu, např. abc1234
git checkout abc1234            # detached HEAD – zobraz stav, aniž bys cokoli měnil
# líbí se ti tento stav? vytvoř z něj větev:
git checkout -b recovery abc1234
# návrat:
git checkout main

Jde o bezpečný „dočasný návrat“. Detached HEAD větev nezmění; vaše současná práce ve větvi main (nebo jiné větvi) zůstane nedotčená. Pokud chcete v tomto stavu pokračovat, vytvořte větev.

Úroveň 4. git reset --hard <commit> – posunutí větve na předchozí bod.

⚠️ Destruktivní. Commity před zadaným hashem osiří.

git reflog                                  # poznamenej si hash aktuálního stavu
git reset --hard abc1234                    # přepiš větev
# našel jsi chybu? vrať se přes reflog:
git reset --hard HEAD@{1}                   # vrať se tam, kde jsi byl před resetem

Používejte pouze tehdy, když jste si jistí, že commity před zadaným bodem nepotřebujete. Před resetem vždy zkontrolujte git reflog, abyste věděli, kam se vrátit, kdybyste si to rozmysleli.

Úroveň 5. git reflog + obnova – katastrofický scénář.

Někdo (Claude, vy nebo kolega) už spustil git reset --hard nebo force-push a smazal práci. Co dělat?

git reflog                                          # hledej poslední hash před havárií
git branch recovered HEAD@{N}                       # vytvoř z něj větev
git checkout recovered                              # přepni se na ni
git diff main                                       # porovnej ji s aktuálním stavem
git checkout main && git merge recovered            # obnov ji do mainu, pokud jsi si jistý

Pokud už byl reflog vymazán (ve výchozím nastavení po 90 dnech), poslední možností je git fsck --lost-found, které zobrazí osiřelé commity v .git/objects/. Je to téměř archeologie, ale někdy funguje.

Pravidlo pro volbu úrovně:

Jak ochránit projekt, aby nebylo co vracet?#

Pravidlo 1. Commitujte každých 30 minut.

Nečekejte, až bude „úkol hotový“. Commitujte každý mezikrok, který funguje. Zpráva commitu může znít jakkoli; důležité je, aby se Claude (nebo vy) mohl jedním příkazem git checkout vrátit do funkčního stavu.

# na začátku úkolu
git status                        # prohlédni všechny připravené i nepřipravené cesty
git diff                          # zkontroluj změny
# Ukázkovou cestu nahraď skutečně prověřeným souborem.
git add -- path/to/file.ts
git diff --cached                 # ověř přesný obsah commitu
git commit -m "wip: starting User schema migration"

# po 30 minutách (nebo po první funkční iteraci)
git status
git diff
git add -- path/to/file.ts         # skutečně prověřená cesta, nikoli zástupný adresář
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# na konci úkolu – smysluplný commit
git reset --soft HEAD~2           # spoj tři wip commity do jednoho
git commit -m "feat(auth): add lastLoginAt field to User table"

Přidáte-li připomínku PostToolUse, zachovejte stejnou kontrolu a přípravu výslovných cest. Časovač neměňte v nekontrolovaný automatický commit: jinak se mohou přimíchat nesouvisející či dříve připravené soubory.

Pravidlo 2. Minimální .gitignore.

V kořeni projektu jsou povinné tyto řádky:

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

# místní nastavení Claude Code (nesdílí se v týmovém repozitáři)
.claude/personal/
.claude/sessions/
.claude/file-history/

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

Složku .claude/personal/ používám pro vlastní experimenty a poznámky, které nemají být ve sdíleném repozitáři. Složky .claude/sessions/ a .claude/file-history/ jsou místním úložištěm Claude Code; do repozitáře nepatří, zabírají hodně místa a jsou svázané s konkrétním počítačem.

Pravidlo 3. Experimenty ve vlastní větvi.

Pokud je úkol rozsáhlý (refaktoring 10+ souborů, migrace na novou databázi, přepis modulu), nepracujte na hlavní větvi:

git checkout -b experiment/auth-rewrite
# pracuj a commituj každých 30 minut
# pokud to funguje:
git checkout main
git merge experiment/auth-rewrite
# pokud ne:
git checkout main
git branch -D experiment/auth-rewrite     # smaž větev
# to je vše, hlavní větev zůstala nedotčená

Tento jednoduchý návyk změní situaci „Claude zničil projekt“ na „Claude zničil jednu větev, smazal jsem ji a můžeme začít znovu“.

Pravidlo 4. Před nebezpečnými operacemi použijte git tag.

Před migrací databáze, rozsáhlým refaktoringem nebo aktualizací závislostí vytvořte tag:

git tag pre-prisma-migration-v2
# pracuj
# něco se pokazilo:
git reset --hard pre-prisma-migration-v2
# nebo se jen podívej:
git checkout pre-prisma-migration-v2

Tag je pojmenovaný ukazatel na commit, o který nepřijdete ani po vyčištění reflogu.

Co dál: jak souvisí vrácení změn se správou kontextu?#

Tyto tři úrovně vrácení změn tvoří základ jedné dovednosti: vědět, jak obnovit stav, když se něco pokazí. Sama o sobě je tato dovednost úzce zaměřená. Ve spojení s dalšími nástroji pro správu kontextu se ale mění v něco víc.

Plan Mode vám nedovolí hned psát kód – nejprve přijde plán, potom potvrzení a až pak provedení. Jde o preventivní vrácení změn: nenapíšete něco, co byste později museli vracet, protože plán byl předem zkontrolován. Přečtěte si více v návodu k Plan Mode v Claude Code.

Soubor CLAUDE.md nastavuje pravidla, kterými se Claude ve výchozím nastavení řídí, včetně výše uvedeného protokolu bezpečnosti gitu. Jde o preventivní ochranu před destruktivními příkazy.

Second Brain poskytuje Claudeovi paměť o projektu mezi relacemi – ví, jaký kód máte, jak funguje obchodní logika a na čem jste se dohodli dříve. Čím více paměti, tím menší pravděpodobnost, že udělá něco špatně.

Skills a subagenti představují vaši metodiku v kódu. Pokud je správný postup práce s gitem součástí Skill, žádný subagent nespustí git reset --hard bez potvrzení.

A to vše dohromady je Context Engineering. Spravujte kontext před zadáním, ne až při jeho zpracování. Více se dozvíte v článku co je context engineering.

Vrácení změn je poslední obrannou linií. Plan Mode + CLAUDE.md + Second Brain + Skills jsou první čtyři. Když jsou nastavené, vrácení změn je vzácné a rychlé. Když nejsou, stává se každodenním rituálem.

Vrácení změn začíná tam, kde končí plánování.

Přejděte na Ailoot.