# Jak cofnąć zmiany w Claude Code: /rewind i git > Tryby cofania, ograniczenia punktów kontrolnych, git checkout, stash, reflog oraz ochrona przed destrukcyjnymi poleceniami. Pięć sposobów na przywrócenie stanu. Source: https://ailoot.ai/blog/pl/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/pl/claude-code-undo-changes/ Language: pl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-3eb9722a6625066f4f9aa7440765984e7fb21a66d8554638e6734ac851eb335e [Praktyczne informacje o korzystaniu z Ailoot znajdziesz w dokumentacji](https://ailoot.ai/docs/). ## Czym jest cofanie w Claude Code i dlaczego trzy poziomy nie wystarczą?
Najważniejsze informacje Cofanie w Claude Code ma trzy poziomy: wbudowane polecenie `/rewind` (natychmiastowe odzyskiwanie w ramach sesji), `git checkout` (przywrócenie stanu z ostatniego commita) i `git reflog` (ostatnia deska ratunku, gdy ktoś uruchomił `git reset --hard`). Każdy poziom obejmuje własną klasę błędów i nic poza jej zakresem. Znajomość samego `/rewind` oznacza, że przy pierwszej poważnej wpadce zostaniesz z niczym.
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:** | Poziom | Polecenie | Obejmuje | NIE obejmuje | |----|----|----|----| | 1\. W ramach sesji | `/rewind` lub `Esc Esc` | Pliki zmienione przez Claude za pomocą jego własnych narzędzi; historię rozmowy | Polecenia Bash, zewnętrzne edytory, migracje baz danych | | 2\. Przed commitem | `git checkout .` lub `git stash` | Wszystkie niezatwierdzone zmiany w plikach | Zatwierdzonych commitów | | 3\. Katastrofa | `git reflog` + `git reset --hard ` | Commity zniszczone przez `reset --hard` lub force-push | Destrukcyjnych poleceń Bash (rm, migracje baz danych) | 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?
Najważniejsze informacje Menu Rewind w Claude Code można otworzyć na dwa sposoby. Pierwszy to wpisanie `/rewind` w polu tekstowym. Drugi to dwukrotne naciśnięcie `Esc`, gdy pole jest puste. Jeśli w polu znajduje się tekst, pierwsze dwukrotne naciśnięcie Esc go wyczyści i zapisze w historii wprowadzania; kolejne dwukrotne naciśnięcie otworzy menu. Polecenie `/rewind` ma alias `/checkpoint`.
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:

Jeśli w polu promptu znajduje się tekst, dwukrotne naciśnięcie Esc najpierw go wyczyści, zamiast otworzyć menu. Wyczyszczony tekst zostanie zapisany w historii wprowadzania, więc po otwarciu menu cofania możesz przywrócić go strzałką w górę.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
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?
Najważniejsze informacje Po wybraniu punktu cofania w menu Rewind pojawia się drugie menu z sześcioma trybami. Trzy przywracają stan (`Restore code and conversation`, `Restore conversation`, `Restore code`), dwa kompresują historię (`Summarize from here`, `Summarize up to here`), a jeden anuluje działanie (`Never mind`). Najczęstszy przypadek — „cofnij zarówno kod, jak i rozmowę” — odpowiada pierwszej opcji.
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:** | Tryb | Działanie | Kiedy wybrać | |----|----|----| | `Restore code and conversation` | Przywraca pliki i historię rozmowy do wybranego punktu | Najczęstszy przypadek: Claude obrał zły kierunek i chcę zacząć od nowa, używając właściwego sformułowania | | `Restore conversation` | Cofa tylko historię rozmowy; pliki pozostają w obecnym stanie | Kod jest dobry, ale rozmowa zeszła na manowce; przeredaguję polecenie od tego miejsca, zachowując bieżące zmiany | | `Restore code` | Cofa pliki; rozmowa pozostaje bez zmian | Niektóre zmiany Claude'a były zbędne, ale nadal potrzebuję kontekstu rozmowy (na przykład uzgodniliśmy kolejne kroki) | | `Summarize from here` | Kompresuje wszystko PO wybranym punkcie do postaci podsumowania. Nie zmienia plików | Długa sesja debugowania wyczerpała kontekst; chcę zwolnić miejsce, zachowując pełne początkowe instrukcje | | `Summarize up to here` | Kompresuje wszystko PRZED wybranym punktem do postaci podsumowania. Nie zmienia plików | Po długim wstępnym omówieniu pojawiło się konkretne zadanie — kompresujemy omówienie do jednej wiadomości i pozostawiamy ostatnią pracę bez zmian | | `Never mind` | Zamyka menu bez wprowadzania zmian | Zmieniłem zdanie | 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:

Możesz kompresować wczesny kontekst za pomocą opcji „Summarize up to here” w menu Rewind.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
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?
Najważniejsze informacje `/rewind` śledzi wyłącznie zmiany wprowadzone przez Claude'a za pomocą jego własnych narzędzi edycji plików. Nie widzi ani nie przywróci niczego innego. Istnieją trzy klasy niewidocznych zmian: polecenia Bash (rm, mv, cp), edycje zewnętrzne (ręczne zmiany w IDE, zmiany z innych sesji) oraz operacje poza plikami (migracje baz danych, git push, wywołania zdalnych API).
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:

Punkty kontrolne nie śledzą plików zmienionych za pomocą poleceń Bash. Na przykład, jeśli Claude Code uruchomi rm file.txt, mv old.txt new.txt lub cp source.txt dest.txt, tych zmian plików nie da się cofnąć za pomocą funkcji rewind.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
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?
Najważniejsze informacje `/rewind` to lokalne cofanie w ramach jednej sesji Claude Code. Przechowuje przyrostowe migawki przez maksymalnie 30 dni, do 100 na sesję. git to długoterminowa historia projektu współdzielona przez zespół, obejmująca gałęzie, konflikty scalania i zdalne repozytorium. Jedno nie zastępuje drugiego. Najlepsza praktyka to tworzenie `git commit` przy każdym logicznym etapie i korzystanie z `/rewind` pomiędzy commitami.
Dokumentacja Anthropic wyraźnie opisuje to połączenie:

Punkty kontrolne zostały zaprojektowane z myślą o szybkim odzyskiwaniu stanu sesji. Do commitów, gałęzi i długoterminowej historii nadal używaj systemu kontroli wersji (na przykład Git). Punkty kontrolne uzupełniają normalną kontrolę wersji, ale jej nie zastępują. Traktuj punkty kontrolne jako „lokalne cofanie”, a Git jako „trwałą historię”.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Różnice zebrane w jednej tabeli: | Parametr | /rewind | git | |----|----|----| | Szczegółowość | Każda tura rozmowy | Każdy commit | | Przechowywanie | Do 30 dni, maksymalnie 100 na sesję, lokalnie w `~/.claude/file-history/` | Trwale, w `.git/` repozytorium i na zdalnym serwerze | | Co śledzi | Zmiany Claude'a wprowadzone jego własnymi narzędziami | Wszystkie zatwierdzone zmiany | | Czego NIE śledzi | Bash, zmiany zewnętrzne, migracje, push | Niezatwierdzone zmiany | | Polecenie | Polecenie w Claude | Zewnętrzny system kontroli wersji | | Cofa rozmowę | Tak | Nie | | Działa między sesjami | Tylko w tej samej sesji | Wszędzie | 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”?
Najważniejsze informacje W języku naturalnym „cofnij” oznacza „sprawdź historię”, a nie „zniszcz ją”; Claude powinien domyślnie proponować `git checkout`, a nie `reset --hard`; zabezpieczenia należy skonfigurować w CLAUDE.md.
Prośba, aby „zapisać bieżący stan i cofnąć do ostatniego push”, może skończyć się takimi poleceniami: ```bash 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 `, 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?
Najważniejsze informacje `git reflog` pokazuje lokalną historię wszystkich przesunięć HEAD w repozytorium — nawet commitów usuniętych przez `git reset --hard` lub force-push. Każde przesunięcie jest domyślnie przechowywane przez 90 dni. Jeśli Claude (albo ty lub ktoś inny) zniszczył commity destrukcyjnym poleceniem, `git reflog` pokaże ich hashe, a gałąź można przywrócić przez `git reset --hard `.
Po destrukcyjnym resecie od razu uruchom `git reflog`: ```bash 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ć: ```bash # 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?
Najważniejsze informacje Dodaj do `CLAUDE.md` projektu blok instrukcji określający, które polecenia git Claude może uruchamiać samodzielnie, które wymagają wyraźnego potwierdzenia, a które są zabronione, jeśli użytkownik nie wypowie dokładnej frazy. Claude traktuje CLAUDE.md jako systemowy prompt projektu i domyślnie przestrzega tych zasad. Dzięki temu jedno „niebezpieczne” polecenie można zastąpić dwoma bezpiecznymi.
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`): ```markdown ## 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 ` (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 `, 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): ```markdown ## 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 ` — zachowam całą pracę, ale tymczasowo pokażę stan z ostatniego push. > 2. DESTRUKCYJNA: `git reset --hard ` — 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?
Najważniejsze informacje Gdy coś pójdzie nie tak, masz pięć poziomów awaryjności: `/rewind` (w ramach sesji), `git checkout .` (niezatwierdzone zmiany), `git checkout ` (powrót do starego commita bez utraty historii), `git reset --hard ` (przesunięcie gałęzi wstecz i utrata późniejszych commitów), `git reflog` + odzyskiwanie (katastrofa, wszystko przepadło). Każdy kolejny poziom jest cięższy i bardziej niebezpieczny od poprzedniego.
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.** ```bash 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ę.** ```bash 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 ` — powrót do starego commita bez utraty historii.** ```bash 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 ` — przesuń gałąź do wcześniejszego punktu.** ⚠️ Działanie destrukcyjne. Commity znajdujące się za wskazanym hashem zostaną osierocone. ```bash 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ć? ```bash 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:** | Co się stało | Poziom | |-----------------------------------------------|-----------------------------| | Claude źle przepisał 3 pliki | 1\. `/rewind` | | Spróbowałem, nie spodobało mi się, a sesja nie pomaga | 2\. `git checkout .` | | Zepsułem coś ręcznie, szkoda mi to stracić, może to przywrócę | 2.5. `git stash` | | Zrobiłem commit; muszę cofnąć się o jeden commit | 3\. `git checkout ` | | Mam pewność, że nie potrzebuję późniejszych commitów | 4\. `git reset --hard` | | Praca została już wymazana destrukcyjnym poleceniem | 5\. `git reflog` | ## Jak zabezpieczyć projekt, żeby nie było czego cofać?
Najważniejsze informacje Najlepsze cofanie to takie, którego nie trzeba wykonywać. Trzy zasady ochrony: przeglądaj postęp co 30 minut i zapisuj działający etap w commicie, jawnie dodając wyłącznie przejrzane ścieżki; dodaj wymagane wpisy `.claude/personal/` i `.env*` do `.gitignore`; większe eksperymenty wykonuj na osobnej gałęzi przez `git checkout -b experiment-`. Ogranicza to lukę odtwarzania dla zacommitowanych plików; systemy zewnętrzne i niezacommitowana praca nadal wymagają własnego planu odzyskania.
**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`. ```bash # 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: ```gitignore # 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: ```bash 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: ```bash 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?
Najważniejsze informacje Cofanie nie jest osobną umiejętnością, lecz częścią zarządzania kontekstem sesji Claude Code. Gdy wiesz, kiedy nacisnąć `/rewind`, kiedy zrobić `git commit` i kiedy użyć `git stash`, zarządzasz całym przepływem pracy, a nie pojedynczym poleceniem. To część **Context Engineering**. Bez niej Claude zachowuje się jak zwykły asystent, a z nią — jak przewidywalne narzędzie.
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](https://ailoot.ai/blog/pl/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/pl/claude-md-template/) 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](https://ailoot.ai/blog/pl/claude-code-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](https://ailoot.ai/blog/pl/claude-code-skills-library/) 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](https://ailoot.ai/blog/pl/context-engineering/). 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.
### Źródła - [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new) - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
Cofanie zaczyna się tam, gdzie kończy się planowanie. [Otwórz Ailoot](https://ailoot.ai/). ## Pytania i odpowiedzi ### Czy punkt kontrolny WIP powinien używać git add .? Nie. Uruchom `git status` i `git diff`, dodaj tylko nazwane pliki, które przejrzałeś, a przed commitem sprawdź `git diff --cached`. Okresowy punkt kontrolny nie zezwala na włączenie niezwiązanych lub wcześniej dodanych zmian. ### Czy /rewind może cofnąć migrację bazy lub działanie zdalnego API? Nie. Przewodnik ogranicza punkty kontrolne do obsługiwanych edycji plików w sesji. Baza danych, zdalny Git i skutki API wymagają osobnych kroków odzyskania; dla plików poza zakresem punktu kontrolnego użyj Git lub kopii zapasowej. ## Ailoot · Firma i jej portfel projektów Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI. Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach. Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.