Jak cofnąć zmiany w Claude Code: /rewind i git

Praktyczne informacje o korzystaniu z Ailoot znajdziesz w dokumentacji.

Czym jest cofanie w Claude Code i dlaczego trzy poziomy nie wystarczą?#

Włączyłem /rewind w pierwszym tygodniu korzystania z Claude Code, gdy w dwóch promptach zepsuł logikę uwierzytelniania w moim projekcie. Cofnąłem zmiany, odetchnąłem i pracowałem dalej. Miesiąc później pojawiła się inna sytuacja: pisałem migrację schematu, Claude mi pomagał, zrobiłem commit, przełączyłem gałąź — i zorientowałem się, że zapomniałem o niezbędnym kroku. /rewind nie pomógł, bo sesja była już inna. Pomogło git checkout do poprzedniego commita. Miesiąc później przez pomyłkę powiedziałem agentowi: „cofnij wszystko do ostatniego push”, a on uruchomił git reset --hard, niszcząc trzy godziny pracy. Uratował mnie git reflog — hashe zniszczonych commitów wciąż tam były.

Te trzy historie pokazują trzy poziomy ochrony, które działają inaczej, wychwytują różne błędy i są potrzebne wszystkie. W tym poradniku wyjaśniam każdy poziom wraz z poleceniami, ograniczeniami i przykładami. Pokazuję też, jak wcześniej skonfigurować projekt, aby Claude nie zniszczył go przy pierwszej okazji.

3 poziomy cofania — co i kiedy:

Dalej omówimy każdy poziom — co dokładnie zrobić, na co uważać i jak skonfigurować projekt, żeby nie było czego cofać, bo nic się nie zepsuło.

Jak uruchomić /rewind: poleceniem czy przez Esc-Esc?#

Po każdej odpowiedzi Claude automatycznie tworzy migawkę wszystkich plików edytowanych w danej sesji. Migawki są przechowywane w ~/.claude/file-history/{sessionId}/ i zachowywane przez maksymalnie 30 dni. Są przyrostowe — zapisywane są tylko różnice między stanami, a nie całe pliki. Domyślnie w jednej sesji przechowywanych jest maksymalnie 100 migawek. Oznacza to, że w większości rzeczywistych projektów w dowolnym momencie masz pełną historię zmian Claude'a z danego dnia pracy.

Aby otworzyć menu cofania, naciśnij dwukrotnie Esc, gdy pole tekstowe jest puste:

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

Jeśli pole tekstowe zawiera tekst, pierwsze dwukrotne naciśnięcie Esc go wyczyści i zapisze w historii Up. To przydatne, gdy zacząłeś już pisać i dopiero wtedy zorientowałeś się, że musisz cofnąć zmiany. Oto cytat z oficjalnej dokumentacji Anthropic:

Polecenie /rewind robi to samo — otwiera menu. Alias /checkpoint prowadzi do tego samego miejsca. Wybór wygodniejszej metody to kwestia przyzwyczajenia. Używam Esc Esc — jest szybciej i nie muszę odrywać rąk od klawiatury.

6 trybów w menu Rewind: który wybrać i kiedy?#

Wybierz punkt na liście, a zobaczysz menu działań. Jest w nim sześć pozycji, z których każda działa inaczej.

Pełna tabela trybów:

Funkcja Summarize up to here pojawiła się w Claude Code v2.1.139-v2.1.142, wydanych w dniach 11–15 maja 2026 roku, w 20. tygodniu:

Różnica między Restore a Summarize jest zasadnicza. Restore przywraca poprzedni stan, cofając wszystko, co wydarzyło się po wybranym punkcie. Summarize niczego nie cofa — tylko kompresuje. Oryginalne wiadomości pozostają w transkrypcie sesji jako materiał referencyjny, ale w aktywnym kontekście pozostaje już tylko podsumowanie. Użyj restore, gdy chcesz, by było „tak, jakby to się nigdy nie wydarzyło”. Użyj summarize, gdy chcesz „zachować to, ale nie zajmować miejsca w kontekście”.

Po wybraniu Restore conversation lub Summarize from here oryginalny tekst wybranego promptu wraca do pola wprowadzania — możesz go edytować i wysłać ponownie. Po Summarize up to here pole jest puste, a ty pozostajesz na końcu rozmowy.

Jakich zmian /rewind NIE cofa?#

To główne ograniczenie, na które trafiają użytkownicy: /rewind pokazuje zielony znacznik wyboru i komunikat „cofanie zakończone powodzeniem”, ale projekt nadal jest zepsuty, bo Claude zmienił coś więcej niż pliki. Przyjrzyjmy się trzem przypadkom.

1. Polecenia Bash nie są śledzone. Jeśli Claude w danej turze uruchomi rm file.txt albo mv old.txt new.txt, te zmiany nie zostaną uwzględnione w punkcie kontrolnym. Dokumentacja Anthropic stwierdza to wprost:

Oznacza to, że jeśli Claude samodzielnie usunie, przeniesie lub skopiuje plik za pomocą narzędzia Bash, /rewind nie przywróci wszystkiego. Pomóc może git checkout lub przywrócenie z kopii zapasowej, ale wymaga to czegoś więcej niż naciśnięcia dwóch klawiszy.

2. Zmiany zewnętrzne nie są wykrywane. Jeśli ręcznie otworzysz plik w VS Code i coś zmienisz albo druga sesja Claude'a równolegle zmieni te same pliki, pierwsza sesja nie zobaczy tych zmian. Migawka punktu kontrolnego powstaje po zakończeniu tury Claude'a w bieżącej sesji. To, co wydarzy się między turami, nie należy do zakresu jego odpowiedzialności.

3. Operacje poza plikami nie są objęte ochroną. Migracja Prisma zastosowana przez npx prisma migrate dev zmienia schemat bazy danych — /rewind jej nie cofnie, ponieważ baza danych znajduje się poza systemem plików projektu. Force-push do origin/main działa tak samo: commit trafił na zdalny serwer, a punkt kontrolny nie może go przywrócić. Zdalne wywołanie API, które pobrało opłatę lub usunęło rekord, można cofnąć wyłącznie za pomocą mechanizmów danego API.

Zasada: Jeśli zadanie wpływa na cokolwiek poza plikami projektu — migracje bazy danych, git push, zdalne API — przygotuj oddzielną strategię wycofania dla każdego zewnętrznego skutku. /rewind obejmuje wyłącznie lokalną historię plików w bieżącej sesji.

Czym różnią się /rewind i git i dlaczego potrzebujesz obu?#

Dokumentacja Anthropic wyraźnie opisuje to połączenie:

Różnice zebrane w jednej tabeli:

Połączenie jest proste: gdy osiągniesz stan „to działa i nie chcę tego stracić”, zrób git commit. Pomiędzy commitami korzystaj z /rewind — działa natychmiast, nie wymaga wiadomości commita i nie zaśmieca historii git stanami pośrednimi. Po zakończeniu pracy zrób commit, najlepiej znaczący i atomowy.

Dlaczego jeden /rewind nie obejmuje całego zadania?#

Cofanie to jeden z przypadków inżynierii kontekstu. Zarządzaj kontekstem sesji (kiedy robić commit, kiedy nacisnąć /rewind, jakie zasady umieścić w CLAUDE.md), a Claude będzie działał przewidywalnie i nie zniszczy projektu ani nie zgubi pracy.

Dlaczego git reset --hard jest groźne, gdy prosisz Claude'a o „cofnięcie”?#

Prośba, aby „zapisać bieżący stan i cofnąć do ostatniego push”, może skończyć się takimi poleceniami:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # zapisano niezatwierdzone zmiany
git reset --hard 35eb731                                                # zniszczono commity d63695e..882e618

Pierwsze polecenie było poprawne — zapisało niezatwierdzone zmiany w stashu. Drugie było destrukcyjne: przepisało gałąź na commit 35eb731, a wszystkie commity między nim a 882e618 stały się osierocone. Domyślnie osierocone commity pozostają w .git/objects/, dopóki nie uruchomi się git gc, co zwykle dzieje się automatycznie w ciągu dwóch tygodni. Jeśli jednak nie wiesz, co zrobić w danej chwili, czas już działa na twoją niekorzyść.

Logika jest prosta: w języku naturalnym „cofnij”, „wróć”, „przywróć”, „odwróć” i „anuluj” oznaczają „spójrz wstecz” lub „wróć do bezpiecznego miejsca”. Nie oznaczają „zniszcz historię”. Polecenie git reset --hard niszczy historię — przepisuje gałąź i usuwa z niej commity, które nie są już osiągalne z HEAD. Bezpieczną alternatywą jest git checkout <commit>, który tworzy detached HEAD i pozwala zobaczyć wcześniejszy stan bez naruszania gałęzi.

Najważniejszy praktyczny wniosek to wykonanie git commit bieżącego stanu przed każdym większym zadaniem, szczególnie przed refaktoryzacją wielu plików. Jeden commit sprawia, że każdą wpadkę Claude'a można naprawić jednym poleceniem git checkout . bez utraty pracy.

Jak git reflog ratuje po destrukcyjnym resecie?#

Po destrukcyjnym resecie od razu uruchom git reflog:

git reflog

Wynik wygląda tak:

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} to właśnie te „zniszczone” commity. Nie zniknęły z lokalnego magazynu obiektów git — stały się jedynie niedostępne przez gałąź. Aby je przywrócić:

# Utwórz gałąź z ostatniego „zniszczonego” commita
git branch recovered-work 882e618

# Albo przełącz się bezpośrednio
git reset --hard 882e618

Po tym gałąź znów zawiera całą historię aż do katastrofy.

Ograniczenia reflog:

1. Tylko lokalnie. Reflog jest przechowywany w .git/logs/HEAD; nie znajduje się w zdalnym repozytorium. Jeśli po force-push usuniesz lokalną kopię repozytorium, reflog zniknie razem z folderem.
2. Domyślnie 90 dni. Starsze wpisy mogą zostać usunięte przez git gc. Możesz skonfigurować ten okres poleceniem git config gc.reflogExpire 200.days.ago.
3. Nie obejmuje tego, co nigdy nie było w HEAD. Jeśli commit znajdował się wyłącznie w stashu, a stash został usunięty, reflog pokaże tylko ostatni stan stasha, a nie jego wewnętrzną historię.

Zasada dla zespołu: nigdy nie uruchamiaj git gc --aggressive zaraz po katastrofie. Najpierw zbadaj sytuację za pomocą reflog i odzyskaj dane; wszystko inne zrób później. Nie usuwaj lokalnego klonu repozytorium, dopóki nie upewnisz się, że wszystko, czego potrzebujesz, zostało wypchnięte.

Jak chronić projekt przed destrukcyjnymi poleceniami git za pomocą CLAUDE.md?#

Problem polega na tym, że Claude domyślnie nie ma kontekstu ochronnego. Interpretuje „cofnij” jako git reset --hard, bo technicznie jest to prawidłowa metoda. Dodaj zabezpieczenia do CLAUDE.md — pliku zawierającego systemowy prompt projektu.

Minimalna reguła (wstaw do CLAUDE.md):

## Git Safety Protocol

- NIGDY nie uruchamiaj destrukcyjnych poleceń git (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), chyba że wyraźnie poproszę o ich wykonanie. Nieuprawnione destrukcyjne działania są niepomocne i mogą doprowadzić do utraty pracy.
- Gdy mówię „cofnij”, „wróć”, „przywróć”, „odwróć” lub „anuluj”, interpretuj to jako polecenia PRZEGLĄDU: użyj `git log`, `git diff`, `git checkout <commit>` (tworzy detached HEAD) albo `git stash` (zachowuje zmiany).
- ZAWSZE poproś o potwierdzenie przed KAŻDYM poleceniem, które:
  - Przenosi HEAD na inny commit w gałęzi
  - Modyfikuje historię commitów
  - Może doprowadzić do utraty niezatwierdzonej pracy
  - Zawiera flagi --hard, --force, --aggressive
- Przed każdym destrukcyjnym poleceniem przedstaw ponumerowane porównanie:
  - BEZPIECZNE: użyj `git checkout <commit>`, aby tymczasowo go obejrzeć
  - DESTRUKCYJNE: użyj `git reset --hard`, aby trwale zniszczyć zmiany
- Zaczekaj na mój wyraźny wybór przed wykonaniem.

Rozszerzona reguła dla zespołu (dodaj do CLAUDE.md w katalogu głównym repozytorium):

## Git Workflow Rules

- Rób commit przy każdym działającym etapie. Przed commitem WIP uruchom `git status` i `git diff`, dodaj tylko jawnie przejrzane pliki nazwane przez `git add -- path/to/file`, a potem sprawdź różnice w indeksie przed commitem. Czasomierz przypomina o przeglądzie, nie zezwala na dodanie całego drzewa roboczego.
- Nie używaj `git add .` ani `git add -A` do commitów Claude'a. Po `git status` + `git diff` wskazuj pliki z nazwy.
- Przed `git push --force` do main zatrzymaj się i zapytaj mnie. W gałęziach funkcjonalnych używaj force-push ostrożnie, tylko jeśli masz pewność, że mogę zaakceptować utratę poprzedniej wersji.
- Podczas rozwiązywania konfliktów scalania nie wybieraj od razu „ours” ani „theirs” — najpierw pokaż mi obie wersje, a potem zdecyduję.
- `.gitignore` musi zawierać `.env*`, `.claude/personal/`, `node_modules/` i `dist/`. Jeśli ich brakuje, dodaj je.

Po dodaniu tych bloków na polecenie „cofnij do ostatniego push” Claude odpowiedziałby tak:

Widzę 3 niezatwierdzone pliki i 4 commity od ostatniego push. Są dwie możliwości:

1. BEZPIECZNA: utworzę gałąź view-last-push poleceniem git checkout <last-push-hash> — zachowam całą pracę, ale tymczasowo pokażę stan z ostatniego push.
2. DESTRUKCYJNA: git reset --hard <last-push-hash> — trwale zniszczę 4 commity i niezatwierdzone zmiany. Można je odzyskać tylko przez git reflog w ciągu 90 dni. Którą opcję wybierasz?

To pół minuty rozmowy zamiast czterech godzin straconej pracy.

Jakie jest 5 sposobów cofania w Claude Code i jak wybrać właściwy?#

Scenariusz „Claude coś zepsuł, muszę to pilnie przywrócić” wymaga przechodzenia po tej drabinie od dołu. Zawsze zaczynaj od poziomu 1.

Poziom 1. /rewind — natychmiastowe cofnięcie w ramach sesji.

Naciśnij Esc Esc albo wpisz /rewind. Wybierz punkt sprzed błędu. Wybierz tryb (zwykle Restore code and conversation). Po chwili wracasz do wcześniejszego stanu i możesz zacząć od nowa. Rozwiązuje 80% przypadków „Claude zrobił coś nie tak”.

Poziom 2. git checkout . — cofnięcie wszystkich niezatwierdzonych zmian.

git diff                    # najpierw sprawdź, co faktycznie się zmieniło
git checkout .              # cofnij wszystkie niezatwierdzone zmiany we wszystkich plikach
# albo wybiórczo:
git checkout -- path/to/file.ts   # tylko jeden plik

Przydatne, gdy /rewind nie zadziałał (na przykład Claude zmienił pliki przez Bash) albo gdy trzeba cofnąć zmiany spoza historii sesji. Wszystkie niezacommitowane zmiany znikną na zawsze. Jeśli możesz tego żałować, najpierw uruchom git stash (zob. poziom 2.5).

Poziom 2.5. git stash — odłóż zmiany na półkę.

git stash save "might still need this"
# wróć do czystego stanu (bez zmian)
# ...
# jeśli zmienisz zdanie — przywróć ze stasha:
git stash pop

Dobry kompromis między „stracić na zawsze” a „zostawić bez zmian”. Stash pozostaje lokalny, dopóki jawnie go nie wyczyścisz.

Poziom 3. git checkout <commit> — powrót do starego commita bez utraty historii.

git log --oneline               # znajdź hash właściwego commita, np. abc1234
git checkout abc1234            # detached HEAD — podgląd bez zmieniania czegokolwiek
# jeśli ten stan ci odpowiada, utwórz z niego gałąź:
git checkout -b recovery abc1234
# powrót:
git checkout main

To bezpieczny „tymczasowy powrót”. Detached HEAD nie zmienia gałęzi; bieżąca praca na main (lub innej gałęzi) pozostaje nienaruszona. Jeśli chcesz pracować w tym stanie, utwórz gałąź.

Poziom 4. git reset --hard <commit> — przesuń gałąź do wcześniejszego punktu.

⚠️ Działanie destrukcyjne. Commity znajdujące się za wskazanym hashem zostaną osierocone.

git reflog                                  # zanotuj hash bieżącego stanu
git reset --hard abc1234                    # przepisz gałąź
# pomyłka? wróć przez reflog:
git reset --hard HEAD@{1}                   # wróć do miejsca sprzed resetu

Użyj tylko wtedy, gdy masz pewność, że nie potrzebujesz późniejszych commitów. Przed resetem zawsze sprawdź też git reflog, żeby wiedzieć, dokąd wrócić, jeśli zmienisz zdanie.

Poziom 5. git reflog + odzyskiwanie — scenariusz katastrofalny.

Ktoś (Claude, ty lub współpracownik) uruchomił już git reset --hard albo force-push i wymazał pracę. Co zrobić?

git reflog                                          # znajdź ostatni hash sprzed katastrofy
git branch recovered HEAD@{N}                       # utwórz z niego gałąź
git checkout recovered                              # przełącz się na nią
git diff main                                       # porównaj z obecnym stanem
git checkout main && git merge recovered            # jeśli masz pewność, przywróć zmiany do main

Jeśli reflog został już wyczyszczony (domyślnie po 90 dniach), ostatnią deską ratunku jest git fsck --lost-found, które pokaże wiszące commity w .git/objects/. To niemal archeologia, ale czasami działa.

Zasada wyboru poziomu:

Jak zabezpieczyć projekt, żeby nie było czego cofać?#

Zasada 1. Rób commit co 30 minut.

Nie czekaj, aż „zadanie będzie skończone”. Zatwierdzaj każdy działający etap pośredni. Treść wiadomości commita może być dowolna — najważniejsze, by Claude (lub ty) mógł wrócić do działającego stanu jednym poleceniem git checkout.

# na początku zadania
git status                        # sprawdź ścieżki w indeksie i poza nim
git diff                          # przejrzyj zmiany
# Zastąp przykładową ścieżkę rzeczywistym przejrzanym plikiem.
git add -- path/to/file.ts
git diff --cached                 # sprawdź dokładnie zawartość commita
git commit -m "wip: starting User schema migration"

# po 30 minutach (lub po pierwszej działającej iteracji)
git status
git diff
git add -- path/to/file.ts         # rzeczywista przejrzana ścieżka, nie wzorzec całego katalogu
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# na końcu zadania — znaczący commit
git reset --soft HEAD~2           # połącz trzy commity wip w jeden
git commit -m "feat(auth): add lastLoginAt field to User table"

Jeśli dodasz przypomnienie PostToolUse, zachowaj tę samą regułę przeglądu i dodawania jawnych ścieżek. Nie zmieniaj czasomierza w niesprawdzony automatyczny commit: w przeciwnym razie mogą do niego trafić niezwiązane zmiany lub pliki już obecne w indeksie.

Zasada 2. Minimalny .gitignore.

W katalogu głównym projektu wymagane są następujące wpisy:

# sekrety
.env
.env.local
.env.*.local

# lokalne ustawienia Claude Code (nie są wysyłane do repozytorium zespołu)
.claude/personal/
.claude/sessions/
.claude/file-history/

# zależności i kompilacja
node_modules/
dist/
.next/
build/

Folder .claude/personal/ przeznaczam na własne eksperymenty i notatki, które nie powinny trafić do współdzielonego repozytorium. Foldery .claude/sessions/ i .claude/file-history/ to lokalne zasoby Claude Code; nie należą do repozytorium, zajmują dużo miejsca i są powiązane z konkretną maszyną.

Zasada 3. Eksperymentuj na osobnej gałęzi.

Jeśli zadanie jest duże (refaktoryzacja ponad 10 plików, migracja do nowej bazy danych, przepisanie modułu), nie wykonuj go na głównej gałęzi:

git checkout -b experiment/auth-rewrite
# praca, commit co 30 minut
# jeśli działa:
git checkout main
git merge experiment/auth-rewrite
# jeśli nie działa:
git checkout main
git branch -D experiment/auth-rewrite     # usuń gałąź
# i tyle, główna gałąź pozostaje nienaruszona

Ten prosty nawyk zmienia sytuację „Claude zniszczył projekt” w „Claude zniszczył jedną gałąź, usunąłem ją i zaczynamy od nowa”.

Zasada 4. Przed niebezpiecznymi operacjami użyj git tag.

Przed migracją bazy danych, dużą refaktoryzacją lub aktualizacją zależności utwórz tag:

git tag pre-prisma-migration-v2
# praca
# jeśli coś poszło nie tak:
git reset --hard pre-prisma-migration-v2
# albo po prostu sprawdź stan:
git checkout pre-prisma-migration-v2

Tag jest nazwanym wskaźnikiem do commita, którego nie stracisz nawet po wyczyszczeniu reflog.

Co dalej: jak cofanie wpisuje się w inżynierię kontekstu?#

Te trzy poziomy cofania stanowią podstawę jednej umiejętności: wiedzy o tym, jak przywrócić stan po awarii. Sama w sobie jest dość wąska, ale połączenie jej z innymi narzędziami inżynierii kontekstu daje znacznie więcej.

Plan Mode nie pozwala od razu pisać kodu — najpierw powstaje plan, potem następuje potwierdzenie, a dopiero później wykonanie. To zapobiegawcze cofanie: nie piszesz czegoś, co później trzeba będzie cofnąć, bo plan został wcześniej sprawdzony. Przeczytaj poradnik o Plan Mode w Claude Code.

CLAUDE.md określa reguły, których Claude domyślnie przestrzega, w tym omówiony wcześniej Git Safety Protocol. To zapobiegawcza ochrona przed destrukcyjnymi poleceniami.

Second Brain zapewnia Claude'owi pamięć projektu między sesjami — wie, jaki masz kod, na czym polega logika biznesowa i jakie ustalenia poczyniono wcześniej. Im więcej pamięci, tym mniejsze prawdopodobieństwo, że zrobi coś niewłaściwego.

Skills i subagenci to twoja metodologia zapisana w kodzie. Jeśli prawidłowy przepływ pracy z git jest wbudowany w Skill, żaden subagent nie uruchomi git reset --hard bez potwierdzenia.

A wszystko to razem to Context Engineering. Zarządzaj kontekstem przed promptem, a nie w jego trakcie. Przeczytaj więcej o tym, czym jest inżynieria kontekstu.

Cofanie to ostatnia linia obrony. Plan Mode + CLAUDE.md + Second Brain + Skills to pierwsze cztery. Gdy są skonfigurowane, cofanie jest rzadkie i szybkie. Gdy ich brakuje, staje się codziennym rytuałem.

Cofanie zaczyna się tam, gdzie kończy się planowanie.

Otwórz Ailoot.