Как откатить изменения в Claude Code: /rewind, git и 5 способов в 2026

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, кейсы, ошибки. Подпишись, чтобы быть в курсе.

Что такое откат в Claude Code и почему трёх уровней мало?

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

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

3 уровня отката - что и когда:

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

Как вызвать /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 его очистит и сохранит в Up-историю. Это полезно, когда ты уже начал печатать и понял, что нужно откатиться. Цитата из официальной документации Anthropic:

Команда /rewind делает то же самое - открывает меню. Есть алиас /checkpoint, который ведёт туда же. Какой способ удобнее - вопрос привычки. Я хожу через Esc Esc - быстрее, не отвлекает от мыши.

6 режимов в Rewind-меню: какой выбрать когда?

Выбрал точку в списке - и попадаешь в меню действий. Шесть пунктов, каждый делает разное.

Полная таблица режимов:

Фича Summarize up to here появилась в Claude Code v2.1.139-v2.1.142, релиз 11-15 мая 2026, неделя 20:

Разница между Restore и Summarize - принципиальная. Restore возвращает состояние, то есть отменяет всё, что произошло после выбранной точки. Summarize ничего не отменяет, он только сжимает - оригинальные сообщения остаются в session-transcript для справки, но в активном контексте остаётся только summary. Используй restore, когда хочешь «как будто этого не было». Используй summarize, когда нужно «оставить, но не занимать место в контексте».

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

Какие изменения /rewind НЕ откатывает?

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

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

Это значит, если Claude по своей инициативе через bash-тул удалил, переместил или скопировал файл - /rewind не вернёт всё назад. Спасёт git checkout или восстановление из бэкапа, но это уже не одно нажатие двух кнопок.

2. Внешние правки не ловятся. Если ты руками открыл файл в VS Code и что-то поправил, или вторая сессия Claude параллельно меняла те же файлы - первая сессия эти изменения не видит. Checkpoint-снимок сделан на момент завершения хода Claude в текущей сессии. Что произошло между ходами - снаружи зоны ответственности.

3. Операции вне файлов не охватываются совсем. Миграция Prisma, применённая через npx prisma migrate dev, изменила схему БД - /rewind это не откатит, потому что БД живёт за пределами файловой системы проекта. Force-push в origin/main - то же самое: коммит уехал к удалённому серверу, чекпойнт его не вернёт. Удалённый вызов API, который списал деньги или удалил запись - откатить можно только средствами API.

Правило: если задача затрагивает что-то за пределами файлов проекта - миграции БД, git push, удалённые API - готовь отдельную стратегию отката для каждого внешнего эффекта. /rewind - только локальная история файлов в текущей сессии.

/rewind vs git: чем они отличаются и зачем оба?

В документации Anthropic эта связка зафиксирована напрямую:

Различия в одной таблице:

Связка простая: каждый раз, когда ты дошёл до состояния «вот это уже работает, не хочу потерять», делай git commit. Между коммитами полагайся на /rewind - он мгновенный, не требует записать сообщение, не засоряет git-историю промежуточными состояниями. Когда работа закончена - коммит, желательно осмысленный, желательно атомарный.

Почему один /rewind не закрывает всю задачу?

Откат - частный случай контекст-инжиниринга. Управляешь контекстом сессии (когда коммитить, когда жать /rewind, какие правила в CLAUDE.md) - получаешь предсказуемый Claude, который не разрушает проект и не теряет работу. Этот гайд закрывает один кирпичик одного из трёх китов методологии: Контекст-инжиниринг даёт инструменты управления, но без Второго мозга (структура business/ + CLAUDE.md) и ИИ-клона (твоя методология в Skills) Claude всё равно будет действовать как обычный ассистент. На практикуме за 3 эфира собираешь все три: ИИ-клон + Второй мозг + Контекст-инжиниринг - именно эта связка превращает Claude из помощника с галлюцинациями в стабильный инструмент.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 14–16 июля  ·  2 000 ₽

Записаться →

Как разработчик потерял 4 часа из-за git reset --hard?

История зафиксирована в GitHub Issue #17190 репозитория anthropics/claude-code (закрыто как дубликат, но детально документировано). Пользователь Jeff Kelling, версия Claude Sonnet 4.5, написал:

Claude выполнил последовательно:

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

Первая команда правильная - сохранила незакоммиченные изменения в stash. Вторая - деструктивная: переписала ветку на коммит 35eb731, и все коммиты между ним и 882e618 стали orphaned (сиротами). По умолчанию orphaned коммиты живут в .git/objects/ до запуска git gc, что обычно происходит автоматически в течение двух недель. Но если в этот момент ты не знал, что делать - время уже работает против тебя.

Сам пользователь сформулировал главный урок в комментарии к issue:

Логика простая: в естественном языке «roll back», «go back», «restore», «revert», «undo» означают «посмотреть назад» или «вернуться в безопасное место». Они не означают «уничтожить историю». Команда git reset --hard именно уничтожает - переписывает ветку и убирает коммиты из достижимых через HEAD. Безопасная альтернатива - git checkout <commit>, которая создаёт detached HEAD и даёт посмотреть старое состояние, не трогая ветки.

Главный практический вывод - перед любой ёмкой задачей, особенно перед рефакторингом нескольких файлов, делать git commit текущего состояния. Один коммит превращает любой косяк Claude в одну команду git checkout . без потери работы.

Как git reflog спасает после деструктивного reset?

История из предыдущего раздела закончилась бы хорошо, если бы Jeff сразу запустил 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 gc может их вычистить. Настраивается через git config gc.reflogExpire 200.days.ago.
3. Не покрывает то, чего никогда не было в HEAD. Если коммит был только в stash и stash был уничтожен - reflog покажет только последнее состояние stash, не его внутреннюю историю.

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

Как защитить проект от разрушающих git-команд через CLAUDE.md?

Бессилие issue #17190 - в том, что у Claude по умолчанию нет защитного контекста. Он трактует «roll back» как 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

- Commit на каждой логической вехе. Если задача длиннее 30 минут и ты ещё не коммитил - сначала `git add . && git commit -m "wip: [что сделано]"`, потом следующий шаг.
- Никогда `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/`. Если их нет - добавь.

После добавления этих блоков следующая фраза «откати к последнему пушу» приведёт к ответу:

Я вижу 3 незакоммиченных файла и 4 коммита впереди последнего пуша. Два варианта:

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

Это полминуты диалога вместо четырёх часов потерянной работы.

Какие 5 способов отката есть в Claude Code и как выбрать нужный?

Сценарий «Claude сломал, нужно срочно вернуть» проходит снизу вверх по этой лестнице. Начинай всегда с уровня 1.

Уровень 1. /rewind - мгновенный откат внутри сессии.

Жми Esc Esc или печатай /rewind. Выбирай точку до момента слома. Выбирай режим (обычно Restore code and conversation). Через секунду ты в прошлом, можешь начать заново. Покрывает 80% случаев «Claude сделал не то».

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

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

Полезно, когда /rewind не сработал (например, Claude трогал файлы через bash) или когда нужна отмена в обход истории сессии. Все изменения, которые не были закоммичены, исчезнут безвозвратно. Если жаль - сначала git stash (см. уровень 2.5).

Уровень 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> - вернуть ветку на точку.

⚠️ Деструктивно. Коммиты впереди указанного хэша становятся orphaned.

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

Используй только если уверен, что коммиты впереди тебе не нужны. И всегда смотри git reflog ДО reset - чтобы знать, куда возвращаться, если передумаешь.

Уровень 5. git reflog + восстановление - катастрофический сценарий.

Кто-то (Claude, ты, коллега) уже сделал git reset --hard или force-push и снёс работу. Что делаешь:

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

Если reflog уже почистился (через 90 дней по умолчанию) - последний шанс это git fsck --lost-found, который покажет «болтающиеся» (dangling) коммиты в .git/objects/. Это уже почти археология, но иногда работает.

Правило выбора уровня:

Как защитить проект, чтобы откатывать было нечего?

Правило 1. Коммит каждые 30 минут.

Не жди «когда задача готова». Любой промежуточный шаг, который работает - коммитится. Сообщения коммитов могут быть любыми, главное - чтобы Claude (или ты) мог откатиться на работающее состояние одним git checkout.

# в начале задачи
git status                        # проверь, что нет лишнего
git add .                         # стейджи всё
git commit -m "wip: начинаю миграцию схемы User"

# через 30 минут (или после первой работающей итерации)
git add .
git commit -m "wip: User-схема готова, миграция применена локально"

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

Можно даже автоматизировать через hook Claude Code. В .claude/settings.json добавляешь PostToolUse-хук, который раз в N минут делает auto-commit.

Правило 2. .gitignore минимум.

В корне проекта обязательны строки:

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

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

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

Папку .claude/personal/ я держу для своих экспериментов и notes, которые не должны попасть в общий репо. Папки .claude/sessions/ и .claude/file-history/ - это локальное хранилище Claude Code, в репо им делать нечего, они весят много и привязаны к конкретной машине.

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

Если задача большая (рефакторинг на 10+ файлов, миграция на новую базу, переписывание модуля), не делай её в основной ветке:

git checkout -b experiment/auth-rewrite
# работаешь, коммитишь каждые 30 минут
# получилось:
git checkout main
git merge experiment/auth-rewrite
# не получилось:
git checkout main
git branch -D experiment/auth-rewrite     # удалить ветку
# и всё, основная ветка целая

Эта простая привычка превращает «Claude разнёс проект» в «Claude разнёс одну ветку, я её удалил, начинаем заново».

Правило 4. Перед опасными операциями - git tag.

Перед миграцией БД, перед массовым рефакторингом, перед обновлением зависимостей - ставь tag:

git tag pre-prisma-migration-v2
# работаешь
# что-то пошло не так:
git reset --hard pre-prisma-migration-v2
# или просто посмотреть:
git checkout pre-prisma-migration-v2

Tag - это именованный указатель на коммит, который ты не потеряешь даже через reflog-cleanup.

Что дальше: как откат вписан в контекст-инжиниринг?

Эти три уровня отката - инфраструктура одного навыка: уметь возвращать состояние, когда оно сломалось. Сам по себе навык узкий. Но в связке с другими инструментами контекст-инжиниринга он превращается в нечто большее.

Plan Mode не даёт тебе сразу написать код - сначала план, потом подтверждение, потом исполнение. Это превентивный откат: ты не пишешь то, что потом придётся откатывать, потому что план просмотрен заранее. Подробнее в гайде про Plan Mode в Claude Code.

CLAUDE.md задаёт правила, которые Claude уважает по умолчанию. Включая Git Safety Protocol, который мы разобрали выше. Это превентивная защита от деструктивных команд.

Второй мозг даёт Claude память о проекте между сессиями - он знает, что у тебя за код, что за бизнес-логика, какие договорённости были раньше. Чем больше памяти - тем меньше шансов, что он сделает не то.

Skills и subagents - твоя методология в коде. Если в Skill зашит правильный git-workflow, ни один subagent не выполнит git reset --hard без подтверждения.

И всё это вместе - Контекст-инжиниринг. Управление контекстом до промпта, не во время. Подробнее - в что такое контекст-инжиниринг.

Откат - последний рубеж защиты. Plan Mode + CLAUDE.md + Второй мозг + Skills - первые четыре. Когда они настроены, откат становится редким и быстрым. Когда нет - становится ежедневным ритуалом.

Откат начинается там, где заканчивается план. Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. 3 эфира, 2 000 ₽. Записи остаются у тебя.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 14–16 июля  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

Подписаться в Telegramили на email