# Как отменить изменения в Claude Code: /rewind и Git > Практическое руководство по отмене изменений в Claude Code: команда /rewind, шесть режимов Rewind, различия с Git, восстановление через git reflog и правила Git Safety в CLAUDE.md. Source: https://ailoot.ai/blog/ru/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/ru/claude-code-undo-changes/ Language: ru Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-4ebe4bb577f7350f825b8e4dd9b3c84754f55c86f6a203df5932a3abf9d76d74 [Практические материалы Ailoot доступны в документации](https://ailoot.ai/docs/). ## Что означает откат в Claude Code и почему одного уровня недостаточно?
Основное В Claude Code предусмотрены три уровня отката: встроенная команда `/rewind` возвращает к прежнему состоянию в текущем сеансе, `git checkout` помогает восстановить состояние до последнего коммита, а `git reflog` служит резервным способом найти коммиты после `git reset --hard`. У каждого способа своя область действия. Если знать только `/rewind`, серьёзную потерю данных может оказаться нечем исправить.
Я начал пользоваться `/rewind` в первую неделю работы с Claude Code: после двух запросов он нарушил логику авторизации в проекте. Я вернулся к прежнему состоянию и продолжил работу. Через месяц ситуация была другой: при подготовке миграции схемы я закоммитил изменения, перешёл на другую ветку и заметил, что пропустил важный шаг. Команда `/rewind` уже не помогала, потому что я был в другом сеансе. Выручил `git checkout` на предыдущий коммит. Ещё через месяц просьба «верни всё к последнему пушу» закончилась запуском `git reset --hard` и потерей трёх часов работы. Команда `git reflog` сохранила хэши коммитов, которые перестали быть доступны из ветки. Эти ситуации показывают три разных уровня защиты. У каждого свои команды, ограничения и типы ошибок, поэтому полезно освоить все три. В руководстве разобраны способы отката, их применение и меры, которые помогают заранее снизить риск повредить проект. **Три уровня отката: назначение и ограничения** | Уровень | Команда | Что позволяет отменить или восстановить | Чего не затрагивает | |----|----|----|----| | 1\. Внутри сеанса | `/rewind` или `Esc Esc` | Файлы, изменённые Claude встроенными инструментами; историю диалога | Команды Bash, внешние редакторы, миграции баз данных | | 2\. До коммита | `git checkout .` или `git stash` | Все незакоммиченные изменения файлов | Изменения, уже включённые в коммиты | | 3\. Восстановление после потери | `git reflog` + `git reset --hard ` | Коммиты, ставшие недоступными после `reset --hard` или force-push | Разрушительные команды Bash (`rm`, миграции баз данных) | Ниже рассмотрим каждый уровень, соответствующие команды и возможные ошибки, а также настройки, которые помогают избегать потери изменений. ## Как открыть /rewind: командой или сочетанием Esc Esc?
Основное Меню Rewind в Claude Code открывается двумя способами: введите `/rewind` в строку запроса или дважды нажмите `Esc`, когда поле ввода пустое. Если там уже есть текст, первое двойное нажатие очистит поле и сохранит текст в истории ввода. Следующее двойное нажатие откроет меню. Команда `/rewind` также доступна под именем `/checkpoint`.
После каждого ответа 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 описано следующее поведение:

Когда в поле запроса есть текст, двойное нажатие Esc сначала очищает его, а не открывает меню. Удалённый из поля текст сохраняется в истории ввода, поэтому после открытия меню Rewind его можно восстановить клавишей со стрелкой вверх.

Источник: официальная документация Anthropic о контрольных точках.
Команда `/rewind` открывает то же меню; `/checkpoint` служит её псевдонимом. Выбирай тот способ, которым удобнее пользоваться. Двойное нажатие `Esc` позволяет сделать это, не отрываясь от клавиатуры. ## Какие шесть режимов есть в меню Rewind и когда они нужны?
Основное После выбора точки в меню Rewind появляется список из шести действий. Три восстанавливают состояние (`Restore code and conversation`, `Restore conversation`, `Restore code`), два сокращают историю (`Summarize from here`, `Summarize up to here`), а последнее закрывает меню без изменений (`Never mind`). Если требуется вернуть и файлы, и диалог, выбери первый режим.
После выбора нужного сообщения откроется меню действий. В нём шесть вариантов с разным назначением. **Все режимы меню** | Режим | Действие | Когда использовать | |----|----|----| | `Restore code and conversation` | Возвращает файлы и историю диалога к выбранной точке | Claude выбрал неверное направление, и ты хочешь начать заново с уточнённым запросом | | `Restore conversation` | Возвращает историю диалога, не меняя файлы | Код тебя устраивает, но разговор отклонился от цели; можно переформулировать запрос и сохранить текущие изменения | | `Restore code` | Возвращает файлы к выбранной точке, сохраняя текущий диалог | Некоторые изменения лишние, но контекст беседы, например договорённости о дальнейших шагах, ещё нужен | | `Summarize from here` | Сокращает в сводку всё после выбранной точки; файлы остаются без изменений | Отладка заняла много контекста, и нужно освободить место, сохранив начальные инструкции | | `Summarize up to here` | Сокращает в сводку всё до выбранной точки; файлы остаются без изменений | Начальная постановка задачи была длинной, а недавнюю работу нужно оставить без изменений | | `Never mind` | Закрывает меню без изменений | Ты передумал выполнять откат или сжатие | Функция `Summarize up to here` появилась в Claude Code v2.1.139-v2.1.142; соответствующий выпуск опубликован 11-15 мая 2026 года, на 20-й неделе:

В меню Rewind можно сократить раннюю часть контекста, выбрав «Summarize up to here».

Источник: раздел Anthropic «Что нового».
`Restore` и `Summarize` решают разные задачи. Режим восстановления возвращает состояние и отменяет изменения после выбранной точки. Сжатие ничего не отменяет: исходные сообщения остаются в журнале сеанса, но в активном контексте их заменяет сводка. Используй восстановление, если нужно вернуться к прежнему состоянию, и сжатие, если историю нужно сохранить, но сократить её объём в контексте. После `Restore conversation` или `Summarize from here` исходный текст выбранного запроса снова появляется в поле ввода: его можно отредактировать и отправить повторно. После `Summarize up to here` поле остаётся пустым, и диалог возвращается к последнему сообщению. ## Какие изменения /rewind не отменяет?
Основное `/rewind` учитывает только изменения файлов, внесённые встроенными инструментами редактирования Claude. Команды Bash, правки из внешних редакторов или других сеансов и действия, не связанные с локальными файлами, ему недоступны. К последней категории относятся, например, миграции баз данных, отправка изменений в Git и удалённые вызовы API.
Это ограничение может сбивать с толку: `/rewind` сообщает об успешном восстановлении, но проект остаётся повреждённым, если изменения были сделаны способом, который контрольные точки не отслеживают. Рассмотрим три таких случая. **1. Команды Bash не отслеживаются.** Если Claude выполнил `rm file.txt` или `mv old.txt new.txt`, эти операции не попадут в контрольную точку. Anthropic прямо указывает на это ограничение в документации:

Контрольные точки не фиксируют изменения файлов, выполненные через команды Bash. Например, если Claude Code запустит `rm file.txt`, `mv old.txt new.txt` или `cp source.txt dest.txt`, отменить эти операции через Rewind нельзя.

Источник: официальная документация 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 и зачем нужны оба способа?
Основное `/rewind` возвращает файлы и диалог к более ранней точке в одном сеансе Claude Code. Снимки хранятся локально, до 30 дней и в количестве до 100 на сеанс. Git ведёт долговременную историю проекта, доступную команде: в ней есть коммиты, ветки, слияния и удалённый репозиторий. Эти инструменты дополняют друг друга. Полезная привычка — фиксировать в Git завершённые этапы работы, а между коммитами пользоваться `/rewind`.
Anthropic описывает назначение этих средств так:

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

Источник: официальная документация Anthropic о контрольных точках.
Сравним основные свойства: | Параметр | /rewind | git | |----|----|----| | Частота сохранения | После каждого хода диалога | При каждом коммите | | Хранение | Локально в `~/.claude/file-history/`, до 30 дней и до 100 снимков за сеанс | Постоянно: в `.git/` репозитория и, если изменения отправлены, на удалённом сервере | | Что отслеживает | Изменения Claude, внесённые встроенными инструментами | Изменения, включённые в коммиты | | Что не отслеживает | Bash, внешние правки, миграции, push | Незакоммиченные изменения | | Где выполняется | В Claude Code | Во внешней системе контроля версий | | Может вернуть диалог | Да | Нет | | Действует между сеансами | Нет, только в текущем сеансе | Да | Практический подход прост: когда достигнуто рабочее состояние, которое нельзя потерять, создай коммит Git. Между коммитами используй `/rewind`: он возвращает локальные изменения без сообщения коммита и не добавляет промежуточные состояния в историю Git. По окончании работы зафиксируй результат осмысленным коммитом. ## Почему одного /rewind недостаточно для отката? Откат — один из инструментов **контекст-инжиниринга**. Управляя состоянием сеанса, решая, когда создавать коммит, когда запускать `/rewind` и какие правила записать в `CLAUDE.md`, можно сделать работу Claude предсказуемее и уменьшить риск потери изменений. ## Почему опасно воспринимать просьбу «откатить» как команду git reset --hard?
Основное Просьба «сохранить текущее состояние и вернуться к последнему пушу» может привести к последовательности `git stash` и `git reset --hard 35eb731`. Первая команда сохраняет незакоммиченные изменения, а вторая разрушительно перемещает ветку и делает более поздние коммиты недоступными из неё. Естественную просьбу об откате следует сначала понимать как просьбу изучить историю; безопаснее предложить `git checkout`. Правила для Git можно прописать в `CLAUDE.md`.
Запрос «сохрани текущее состояние и вернись к последнему пушу» может привести к таким командам: ```bash 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 `: он переключает репозиторий в detached HEAD, не передвигая ветку. Перед крупной задачей, особенно рефакторингом нескольких файлов, полезно создать коммит текущего состояния. Тогда многие ошибки можно исправить командой `git checkout .`, не теряя зафиксированную работу. ## Как git reflog помогает после разрушительного сброса?
Основное `git reflog` показывает локальные перемещения `HEAD`, в том числе состояния до `git reset --hard` и force-push. По умолчанию записи хранятся 90 дней. Если деструктивная операция сделала коммиты недоступными из ветки, найдите их хэши в reflog и восстановите ветку с помощью `git reset --hard `.
После разрушительного сброса сразу выполни `git reflog`: ```bash 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, хотя ссылка на них была перемещена. Вернуть коммит можно, например, так: ```bash # Создать ветку из последнего коммита, ставшего недоступным из прежней ветки 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.md` можно описать, какие команды Claude вправе запускать самостоятельно, для каких нужно явное подтверждение и какие нельзя выполнять без прямого указания. Файл задаёт инструкции проекта. Чёткие правила помогают заменять опасную трактовку просьбы «откати» безопасными действиями.
Без дополнительных правил Claude может выбрать `git reset --hard` как технически подходящий способ переместить ветку назад. Защитные инструкции проекта можно записать в `CLAUDE.md`. **Базовый набор правил** для `CLAUDE.md`: ```markdown ## 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 ` (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 ` to view temporarily - DESTRUCTIVE: use `git reset --hard` to permanently destroy - Wait for my explicit choice before executing. ``` **Расширенный набор правил** для `CLAUDE.md` в корне репозитория: ```markdown ## 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 ` и временно посмотреть это состояние; работа останется сохранённой. > 2. DESTRUCTIVE: выполнить `git reset --hard `; это сделает 4 коммита и незакоммиченные правки недоступными. Найти прежние коммиты можно будет через `git reflog` в течение 90 дней. Какой вариант выбрать? Такой обмен помогает заранее прояснить последствия команды. ## Какие пять способов отката доступны в Claude Code?
Основное Для возврата к прежнему состоянию можно использовать пять способов разной степени риска: `/rewind` для текущего сеанса; `git checkout .` для незакоммиченных файлов; `git checkout ` для просмотра состояния на прежнем коммите; `git reset --hard ` для перемещения ветки с потерей более поздних коммитов; `git reflog` для поиска состояния после разрушительной операции. Начинай с наименее опасного способа, подходящего к ситуации.
Если Claude внёс нежелательные изменения, выбирай способ с учётом того, что именно нужно вернуть. Начни с первого уровня, если он применим. **Уровень 1. `/rewind` — возврат внутри сеанса.** Нажми `Esc Esc` или введи `/rewind`. Выбери сообщение до нежелательных изменений, затем обычно используй `Restore code and conversation`. После возврата можно сформулировать задачу заново. Этот способ подходит для многих случаев, когда Claude изменил файлы встроенными инструментами не так, как требовалось. **Уровень 2. `git checkout .` — отмена незакоммиченных изменений.** ```bash git diff # сначала проверь, какие файлы изменены git checkout . # отменить все незакоммиченные изменения во всех файлах # или выборочно: git checkout -- path/to/file.ts # только один файл ``` Это может помочь, если `/rewind` не охватывает правки, например сделанные через Bash, или если нужно отменить изменения независимо от истории сеанса. Незакоммиченные правки будут потеряны. Чтобы сначала сохранить их, выполни `git stash`. **Уровень 2.5. `git stash` — временно убрать изменения.** ```bash git stash save "может, ещё понадобится" # вернуться к чистому состоянию (без правок) # ... # если передумал - вернуть из stash: git stash pop ``` Stash позволяет временно убрать изменения, сохранив возможность вернуть их. Запись остаётся локально, пока ты её не удалишь. **Уровень 3. `git checkout ` — посмотреть старый коммит без перемещения ветки.** ```bash git log --oneline # найди хэш нужного коммита, например abc1234 git checkout abc1234 # detached HEAD - смотришь, ничего не меняешь # если нужно продолжить работу с этого состояния - создай ветку: git checkout -b recovery abc1234 # вернуться обратно: git checkout main ``` Это временный способ открыть старое состояние. Detached HEAD не перемещает текущую ветку `main` или другую активную ветку. Если нужно продолжить работу с выбранного коммита, создай отдельную ветку. **Уровень 4. `git reset --hard ` — переместить ветку на выбранный коммит.** ⚠️ Эта команда разрушительна: коммиты после указанного состояния становятся недоступными из ветки. ```bash git reflog # запомни хэш текущего состояния git reset --hard abc1234 # переместить ветку на выбранный коммит # если понадобится вернуть прежнее состояние: git reset --hard HEAD@{1} # туда, где ветка находилась до reset ``` Применяй команду, только если уверен, что более поздние коммиты не нужны. Перед сбросом проверь `git reflog`, чтобы знать, как найти прежнее положение ветки. **Уровень 5. `git reflog` и восстановление — поиск после потери коммитов.** Если `git reset --hard` или force-push сделал работу недоступной, найди прежнее состояние через reflog: ```bash 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/`; в некоторых случаях это позволяет найти потерянные изменения. **Как выбрать способ отката** | Ситуация | Уровень | |-----------------------------------------------|-----------------------------| | Claude изменил три файла не так, как нужно | 1\. `/rewind` | | Результат не подходит, а меню сеанса не помогает | 2\. `git checkout .` | | Изменения хочется сохранить на случай, если они пригодятся | 2.5. `git stash` | | Изменения закоммичены, нужно открыть прежнее состояние | 3\. `git checkout ` | | Более поздние коммиты точно не нужны | 4\. `git reset --hard` | | Изменения уже сделаны недоступными деструктивной командой | 5\. `git reflog` | ## Как подготовить проект, чтобы реже приходилось откатывать изменения?
Основное Снизить риск потери работы помогут регулярные коммиты, подходящие правила `.gitignore` и отдельные ветки для крупных экспериментов. Фиксируй рабочие этапы, проверь, что в Git не попадают локальные настройки Claude и секреты, а большие изменения выполняй отдельно от основной ветки.
**Правило 1. Коммить по мере работы.** Не жди полного завершения задачи. Фиксируй промежуточный результат, когда он уже работает. Это позволит вернуть проект к сохранённому состоянию, если следующий шаг пойдёт не по плану. ```bash # в начале задачи 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`.** В корне проекта можно добавить, например, такие строки: ```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. Изолируй крупные эксперименты в отдельной ветке.** Для больших изменений — например, рефакторинга десяти и более файлов, миграции на новую базу или переписывания модуля — можно создать отдельную ветку: ```bash git checkout -b experiment/auth-rewrite # работай и фиксируй изменения по мере продвижения # если результат подходит: git checkout main git merge experiment/auth-rewrite # если результат не подходит: git checkout main git branch -D experiment/auth-rewrite # удалить ветку # основная ветка останется без этих изменений ``` Так крупный эксперимент можно отделить от основной ветки и удалить его ветку, если результат не подходит. **Правило 4. Перед рискованными изменениями сохраняй ориентир.** Перед миграцией базы, массовым рефакторингом или обновлением зависимостей можно пометить текущий коммит тегом: ```bash git tag pre-prisma-migration-v2 # работаешь # если результат не подошёл: git reset --hard pre-prisma-migration-v2 # или только посмотреть сохранённое состояние: git checkout pre-prisma-migration-v2 ``` Тег — это именованная ссылка на коммит, к которой можно вернуться и после того, как прежние записи reflog будут очищены. ## Как откат связан с контекст-инжинирингом?
Основное Откат — часть управления контекстом сеанса Claude Code. Понимая, когда создавать коммит, использовать `git stash` или запускать `/rewind`, можно лучше контролировать ход работы. Это один из элементов **контекст-инжиниринга**.
Перечисленные способы помогают вернуть состояние, если что-то пошло не так. Их можно сочетать с другими настройками работы в Claude Code. [Plan Mode в Claude Code](https://ailoot.ai/blog/ru/claude-code-plan-mode/) позволяет сначала подготовить план и проверить его, а уже потом переходить к реализации. Это помогает заметить проблему до внесения изменений. Файл [CLAUDE.md](https://ailoot.ai/blog/ru/kak-nastroit-claude-md/) задаёт инструкции для проекта, в том числе правила безопасной работы с Git, описанные выше. [Второй мозг](https://ailoot.ai/blog/ru/claude-code-second-brain/) помогает Claude сохранять сведения о проекте между сеансами: например, о коде, логике продукта и предыдущих договорённостях. [Skills и subagents](https://ailoot.ai/blog/ru/claude-code-skills-library/) позволяют описать повторяемый процесс в виде инструкций. В Skill можно закрепить порядок работы с Git и требование не запускать `git reset --hard` без явного указания. Все эти способы помогают управлять контекстом и правилами до начала работы. Подробнее — в руководстве [о контекст-инжиниринге](https://ailoot.ai/blog/ru/context-engineering/). Откат остаётся способом восстановить состояние после ошибки. Предварительное планирование, правила в `CLAUDE.md`, сведения о проекте и инструкции Skills помогают уменьшить вероятность таких ситуаций.
### Источники - [Документация Anthropic: контрольные точки](https://code.claude.com/docs/en/checkpointing) - [Anthropic: что нового, 20-я неделя, 11-15 мая 2026 года](https://code.claude.com/docs/en/whats-new) - [Документация Anthropic: режимы разрешений](https://code.claude.com/docs/en/permission-modes) - [Git: документация по команде reflog](https://git-scm.com/docs/git-reflog)
Начни с правил и плана работы, а способы отката используй, когда нужно вернуть прежнее состояние. [Открыть Ailoot](https://ailoot.ai/). ## Вопросы и ответы ### Стоит ли использовать git add . для контрольного WIP-коммита? Нет. Проверь git status и git diff, добавь только просмотренные именованные файлы, затем изучи git diff --cached. Периодическая фиксация не разрешает включать чужие или прежде добавленные в индекс изменения. ### Может ли /rewind отменить миграцию базы или действие удалённого API? Нет. Контрольные точки руководства охватывают поддерживаемые изменения файлов сессии. Базе, удалённому Git и API нужны отдельные шаги восстановления. Для файлов вне охвата используй Git или резервную копию. ## Ailoot · Компания и портфель её проектов Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI. Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно. Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.