Как отменить изменения в Claude Code: /rewind и Git

Практические материалы Ailoot доступны в документации.

Что означает откат в Claude Code и почему одного уровня недостаточно?#

Я начал пользоваться /rewind в первую неделю работы с Claude Code: после двух запросов он нарушил логику авторизации в проекте. Я вернулся к прежнему состоянию и продолжил работу. Через месяц ситуация была другой: при подготовке миграции схемы я закоммитил изменения, перешёл на другую ветку и заметил, что пропустил важный шаг. Команда /rewind уже не помогала, потому что я был в другом сеансе. Выручил git checkout на предыдущий коммит. Ещё через месяц просьба «верни всё к последнему пушу» закончилась запуском git reset --hard и потерей трёх часов работы. Команда git reflog сохранила хэши коммитов, которые перестали быть доступны из ветки.

Эти ситуации показывают три разных уровня защиты. У каждого свои команды, ограничения и типы ошибок, поэтому полезно освоить все три. В руководстве разобраны способы отката, их применение и меры, которые помогают заранее снизить риск повредить проект.

Три уровня отката: назначение и ограничения

Ниже рассмотрим каждый уровень, соответствующие команды и возможные ошибки, а также настройки, которые помогают избегать потери изменений.

Как открыть /rewind: командой или сочетанием Esc Esc?#

После каждого ответа Claude автоматически сохраняет контрольную точку для файлов, которые он редактировал в этом сеансе. Снимки хранятся в ~/.claude/file-history/{sessionId}/ не более 30 дней. Они инкрементальные: записывается разница между состояниями, а не копия файла целиком. По умолчанию для одного сеанса сохраняется до 100 снимков. Поэтому в большинстве обычных проектов можно просмотреть изменения Claude за рабочий день.

Чтобы открыть меню отката, при пустом поле ввода дважды нажми Esc:

[user-input is empty]
> _

[press Esc, Esc]

Rewind to which message?
  1. Сделай миграцию для User-таблицы          (3 файла изменены)
  2. Добавь поле lastLoginAt                    (1 файл изменён)
  3. Перепиши логику авторизации                (5 файлов изменены)
  ...

Если в поле уже набран запрос, двойное нажатие Esc очистит его и сохранит в истории ввода. Это удобно, если ты начал формулировать запрос, а затем решил сначала вернуться к предыдущему состоянию. В официальной документации Anthropic описано следующее поведение:

Команда /rewind открывает то же меню; /checkpoint служит её псевдонимом. Выбирай тот способ, которым удобнее пользоваться. Двойное нажатие Esc позволяет сделать это, не отрываясь от клавиатуры.

Какие шесть режимов есть в меню Rewind и когда они нужны?#

После выбора нужного сообщения откроется меню действий. В нём шесть вариантов с разным назначением.

Все режимы меню

Функция Summarize up to here появилась в Claude Code v2.1.139-v2.1.142; соответствующий выпуск опубликован 11-15 мая 2026 года, на 20-й неделе:

Restore и Summarize решают разные задачи. Режим восстановления возвращает состояние и отменяет изменения после выбранной точки. Сжатие ничего не отменяет: исходные сообщения остаются в журнале сеанса, но в активном контексте их заменяет сводка. Используй восстановление, если нужно вернуться к прежнему состоянию, и сжатие, если историю нужно сохранить, но сократить её объём в контексте.

После Restore conversation или Summarize from here исходный текст выбранного запроса снова появляется в поле ввода: его можно отредактировать и отправить повторно. После Summarize up to here поле остаётся пустым, и диалог возвращается к последнему сообщению.

Какие изменения /rewind не отменяет?#

Это ограничение может сбивать с толку: /rewind сообщает об успешном восстановлении, но проект остаётся повреждённым, если изменения были сделаны способом, который контрольные точки не отслеживают. Рассмотрим три таких случая.

1. Команды Bash не отслеживаются. Если Claude выполнил rm file.txt или mv old.txt new.txt, эти операции не попадут в контрольную точку. Anthropic прямо указывает на это ограничение в документации:

Поэтому удалённый, перемещённый или скопированный Claude через Bash файл не обязательно удастся вернуть с помощью /rewind. Может потребоваться восстановление через git checkout или из резервной копии — это уже не действие в меню.

2. Изменения извне остаются незамеченными. Если ты отредактировал файл вручную в VS Code или его параллельно менял другой сеанс Claude, текущий сеанс эти правки не учитывает. Контрольная точка фиксирует состояние после хода Claude в этом сеансе. Изменения, внесённые между ходами извне, находятся за пределами её охвата.

3. Внешние операции не затрагиваются. Например, npx prisma migrate dev может изменить схему базы данных, но /rewind не вернёт базу в прежнее состояние: она находится за пределами файлов проекта. То же относится к force-push в origin/main — изменение уже отправлено на удалённый сервер. Удалённый вызов API, списавший деньги или удаливший запись, можно компенсировать только средствами самого API.

Практическое правило: если задача затрагивает ресурсы за пределами файлов проекта — базу данных, удалённый Git-репозиторий или внешний API, — заранее продумай отдельный способ отменить каждое такое действие. /rewind охватывает только локальную историю файлов в текущем сеансе.

Чем отличаются /rewind и Git и зачем нужны оба способа?#

Anthropic описывает назначение этих средств так:

Сравним основные свойства:

Практический подход прост: когда достигнуто рабочее состояние, которое нельзя потерять, создай коммит Git. Между коммитами используй /rewind: он возвращает локальные изменения без сообщения коммита и не добавляет промежуточные состояния в историю Git. По окончании работы зафиксируй результат осмысленным коммитом.

Почему одного /rewind недостаточно для отката?#

Откат — один из инструментов контекст-инжиниринга. Управляя состоянием сеанса, решая, когда создавать коммит, когда запускать /rewind и какие правила записать в CLAUDE.md, можно сделать работу Claude предсказуемее и уменьшить риск потери изменений.

Почему опасно воспринимать просьбу «откатить» как команду git reset --hard?#

Запрос «сохрани текущее состояние и вернись к последнему пушу» может привести к таким командам:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # сохранил незакоммиченные правки
git reset --hard 35eb731                                                # сделал коммиты d63695e..882e618 недоступными из ветки

Первая команда сохраняет незакоммиченные изменения в stash. Вторая переписывает состояние ветки, перемещая её на коммит 35eb731; коммиты между ним и 882e618 больше не достижимы через эту ветку. Обычно такие недостижимые коммиты остаются в .git/objects/ до очистки командой git gc, которая, как правило, выполняется автоматически в течение двух недель. Если не знать, как восстановить их до очистки, времени на поиск может остаться мало.

В обычном разговоре «откати», «вернись», «восстанови», «отмени» чаще означают вернуться к безопасному состоянию или посмотреть историю. Они сами по себе не означают, что историю нужно уничтожить. git reset --hard перемещает ветку и делает прежние коммиты недостижимыми из HEAD. Более безопасный способ изучить старое состояние — git checkout <commit>: он переключает репозиторий в detached HEAD, не передвигая ветку.

Перед крупной задачей, особенно рефакторингом нескольких файлов, полезно создать коммит текущего состояния. Тогда многие ошибки можно исправить командой git checkout ., не теряя зафиксированную работу.

Как git reflog помогает после разрушительного сброса?#

После разрушительного сброса сразу выполни git reflog:

git reflog

Пример вывода:

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} соответствуют коммитам, которые перестали быть доступны из ветки. Они всё ещё могут находиться в локальном хранилище объектов Git, хотя ссылка на них была перемещена. Вернуть коммит можно, например, так:

# Создать ветку из последнего коммита, ставшего недоступным из прежней ветки
git branch recovered-work 882e618

# Или переместить текущую ветку на этот коммит
git reset --hard 882e618

После этого восстановленная ветка снова указывает на нужную историю.

Ограничения reflog:

1. Только локальное хранение. Reflog расположен в .git/logs/HEAD и не копируется на удалённый сервер. Если после force-push удалить локальный клон репозитория, reflog также исчезнет.
2. По умолчанию записи хранятся 90 дней. После этого Git может удалить их при очистке объектов. Срок можно настроить командой git config gc.reflogExpire 200.days.ago.
3. В reflog нет состояний, которых не было в HEAD. Если коммит существовал только в stash, а сам stash удалили, reflog покажет перемещения ссылки stash, но не полную историю его содержимого.

Правило для команды: после инцидента не запускай git gc --aggressive, пока не проверишь reflog и не восстановишь нужные состояния. Не удаляй локальный клон, пока не убедишься, что все важные изменения сохранены.

Как задать правила безопасности Git в CLAUDE.md?#

Без дополнительных правил Claude может выбрать git reset --hard как технически подходящий способ переместить ветку назад. Защитные инструкции проекта можно записать в CLAUDE.md.

Базовый набор правил для CLAUDE.md:

## Git Safety Protocol

- NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless I explicitly request these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work.
- When I say "roll back", "go back", "restore", "revert", "undo" - interpret as REVIEW commands: use `git log`, `git diff`, `git checkout <commit>` (creates detached HEAD), or `git stash` (preserves changes).
- ALWAYS ask for confirmation before ANY command that:
  - Changes HEAD position to a different commit on a branch
  - Modifies commit history
  - Could lose uncommitted work
  - Includes flags --hard, --force, --aggressive
- Before any destructive command, output a numbered comparison:
  - SAFE: use `git checkout <commit>` to view temporarily
  - DESTRUCTIVE: use `git reset --hard` to permanently destroy
- Wait for my explicit choice before executing.

Расширенный набор правил для CLAUDE.md в корне репозитория:

## Git Workflow Rules

- Фиксируй каждый работающий этап. Перед WIP-коммитом проверь `git status` и `git diff`, добавь только явно просмотренные именованные файлы через `git add -- path/to/file`, затем проверь индекс перед коммитом. Таймер напоминает о просмотре, а не разрешает добавлять всё рабочее дерево.
- Никогда `git add .` или `git add -A` для коммитов от Claude. Только конкретные файлы по имени, после `git status` + `git diff`.
- Перед `git push --force` в main - стоп, спроси меня. В feature-ветках force-push с осторожностью, только если уверен, что я готов потерять предыдущую версию.
- При работе с merge-конфликтами никогда не выбирай "ours" или "theirs" сразу - сначала покажи мне обе версии, потом я решу.
- `.gitignore` обязан содержать `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. Если их нет - добавь.

При настройке таких правил на просьбу «вернись к последнему пушу» Claude может сначала описать обнаруженное состояние и предложить варианты:

В рабочем каталоге есть 3 незакоммиченных файла и 4 коммита после последнего push. Можно сделать следующее:

1. SAFE: перейти к коммиту последнего push командой git checkout <last-push-hash> и временно посмотреть это состояние; работа останется сохранённой.
2. DESTRUCTIVE: выполнить git reset --hard <last-push-hash>; это сделает 4 коммита и незакоммиченные правки недоступными. Найти прежние коммиты можно будет через git reflog в течение 90 дней. Какой вариант выбрать?

Такой обмен помогает заранее прояснить последствия команды.

Какие пять способов отката доступны в Claude Code?#

Если Claude внёс нежелательные изменения, выбирай способ с учётом того, что именно нужно вернуть. Начни с первого уровня, если он применим.

Уровень 1. /rewind — возврат внутри сеанса.

Нажми Esc Esc или введи /rewind. Выбери сообщение до нежелательных изменений, затем обычно используй Restore code and conversation. После возврата можно сформулировать задачу заново. Этот способ подходит для многих случаев, когда Claude изменил файлы встроенными инструментами не так, как требовалось.

Уровень 2. git checkout . — отмена незакоммиченных изменений.

git diff                    # сначала проверь, какие файлы изменены
git checkout .              # отменить все незакоммиченные изменения во всех файлах
# или выборочно:
git checkout -- path/to/file.ts   # только один файл

Это может помочь, если /rewind не охватывает правки, например сделанные через Bash, или если нужно отменить изменения независимо от истории сеанса. Незакоммиченные правки будут потеряны. Чтобы сначала сохранить их, выполни git stash.

Уровень 2.5. git stash — временно убрать изменения.

git stash save "может, ещё понадобится"
# вернуться к чистому состоянию (без правок)
# ...
# если передумал - вернуть из stash:
git stash pop

Stash позволяет временно убрать изменения, сохранив возможность вернуть их. Запись остаётся локально, пока ты её не удалишь.

Уровень 3. git checkout <commit> — посмотреть старый коммит без перемещения ветки.

git log --oneline               # найди хэш нужного коммита, например abc1234
git checkout abc1234            # detached HEAD - смотришь, ничего не меняешь
# если нужно продолжить работу с этого состояния - создай ветку:
git checkout -b recovery abc1234
# вернуться обратно:
git checkout main

Это временный способ открыть старое состояние. Detached HEAD не перемещает текущую ветку main или другую активную ветку. Если нужно продолжить работу с выбранного коммита, создай отдельную ветку.

Уровень 4. git reset --hard <commit> — переместить ветку на выбранный коммит.

⚠️ Эта команда разрушительна: коммиты после указанного состояния становятся недоступными из ветки.

git reflog                                  # запомни хэш текущего состояния
git reset --hard abc1234                    # переместить ветку на выбранный коммит
# если понадобится вернуть прежнее состояние:
git reset --hard HEAD@{1}                   # туда, где ветка находилась до reset

Применяй команду, только если уверен, что более поздние коммиты не нужны. Перед сбросом проверь git reflog, чтобы знать, как найти прежнее положение ветки.

Уровень 5. git reflog и восстановление — поиск после потери коммитов.

Если git reset --hard или force-push сделал работу недоступной, найди прежнее состояние через reflog:

git reflog                                          # найди хэш до деструктивной операции
git branch recovered HEAD@{N}                       # создай ветку с найденного состояния
git checkout recovered                              # переключись на неё
git diff main                                       # сравни с текущей веткой main
git checkout main && git merge recovered            # верни изменения в main, если проверил результат

Если записи reflog уже очищены — по умолчанию это может произойти по истечении 90 дней, — можно попробовать git fsck --lost-found. Команда ищет недостижимые коммиты в .git/objects/; в некоторых случаях это позволяет найти потерянные изменения.

Как выбрать способ отката

Как подготовить проект, чтобы реже приходилось откатывать изменения?#

Правило 1. Коммить по мере работы.

Не жди полного завершения задачи. Фиксируй промежуточный результат, когда он уже работает. Это позволит вернуть проект к сохранённому состоянию, если следующий шаг пойдёт не по плану.

# в начале задачи
git status                        # просмотри пути в индексе и рабочей папке
git diff                          # проверь изменения
# Вместо примера укажи настоящий просмотренный файл.
git add -- path/to/file.ts
git diff --cached                 # проверь точный состав коммита
git commit -m "wip: начинаю миграцию схемы User"

# через 30 минут или после работающей итерации
git status
git diff
git add -- path/to/file.ts         # настоящий просмотренный файл
git diff --cached
git commit -m "wip: User-схема готова, миграция применена локально"

# в конце задачи - осмысленный коммит
git reset --soft HEAD~2           # объединить три wip-коммита в один
git commit -m "feat(auth): добавлено поле lastLoginAt в User-таблицу"

Если добавляешь напоминание PostToolUse, сохраняй просмотр и добавление только явных путей. Не превращай таймер в непроверяемый автокоммит: иначе туда попадут чужие правки или ранее добавленные в индекс файлы.

Правило 2. Настрой .gitignore.

В корне проекта можно добавить, например, такие строки:

# секреты
.env
.env.local
.env.*.local

# локальные настройки Claude Code (не пушим в репозиторий команды)
.claude/personal/
.claude/sessions/
.claude/file-history/

# зависимости и сборка
node_modules/
dist/
.next/
build/

Каталоги .claude/personal/, .claude/sessions/ и .claude/file-history/ могут содержать личные материалы, данные сеансов и локальные контрольные точки. Убедись, что эти файлы не попадут в общий репозиторий, если им там не место.

Правило 3. Изолируй крупные эксперименты в отдельной ветке.

Для больших изменений — например, рефакторинга десяти и более файлов, миграции на новую базу или переписывания модуля — можно создать отдельную ветку:

git checkout -b experiment/auth-rewrite
# работай и фиксируй изменения по мере продвижения
# если результат подходит:
git checkout main
git merge experiment/auth-rewrite
# если результат не подходит:
git checkout main
git branch -D experiment/auth-rewrite     # удалить ветку
# основная ветка останется без этих изменений

Так крупный эксперимент можно отделить от основной ветки и удалить его ветку, если результат не подходит.

Правило 4. Перед рискованными изменениями сохраняй ориентир.

Перед миграцией базы, массовым рефакторингом или обновлением зависимостей можно пометить текущий коммит тегом:

git tag pre-prisma-migration-v2
# работаешь
# если результат не подошёл:
git reset --hard pre-prisma-migration-v2
# или только посмотреть сохранённое состояние:
git checkout pre-prisma-migration-v2

Тег — это именованная ссылка на коммит, к которой можно вернуться и после того, как прежние записи reflog будут очищены.

Как откат связан с контекст-инжинирингом?#

Перечисленные способы помогают вернуть состояние, если что-то пошло не так. Их можно сочетать с другими настройками работы в Claude Code.

Plan Mode в Claude Code позволяет сначала подготовить план и проверить его, а уже потом переходить к реализации. Это помогает заметить проблему до внесения изменений.

Файл CLAUDE.md задаёт инструкции для проекта, в том числе правила безопасной работы с Git, описанные выше.

Второй мозг помогает Claude сохранять сведения о проекте между сеансами: например, о коде, логике продукта и предыдущих договорённостях.

Skills и subagents позволяют описать повторяемый процесс в виде инструкций. В Skill можно закрепить порядок работы с Git и требование не запускать git reset --hard без явного указания.

Все эти способы помогают управлять контекстом и правилами до начала работы. Подробнее — в руководстве о контекст-инжиниринге.

Откат остаётся способом восстановить состояние после ошибки. Предварительное планирование, правила в CLAUDE.md, сведения о проекте и инструкции Skills помогают уменьшить вероятность таких ситуаций.

Начни с правил и плана работы, а способы отката используй, когда нужно вернуть прежнее состояние.

Открыть Ailoot.