Хотите заказать веб-сайт? Связаться с нами

Вперёд и назад во времени: откат изменений

Мы уже научились управлять сессией агента, формулировать запросы в терминале и выстроили связку с IDE. Но любая работа с агентом — это серия экспериментов: часть изменений оказывается удачной, а часть приходится отменять. В этом уроке разберём, как двигаться по времени проекта в обе стороны: фиксировать состояние через чек-поинты, откатывать неудачные изменения и возвращаться к рабочей точке без потери полезного прогресса.

Вперёд и назад во времени: откат изменений

Почему умение откатывать — обязательный навык

Агент работает быстро и решительно: за один ход он может изменить десяток файлов. Но скорость не гарантирует правильность — часть изменений придётся отменять, и это нормально. Вопрос не в том, случится ли неудачное изменение, а в том, насколько дёшево будет от него отказаться.

Представьте две ситуации. В первой вы после каждого ответа агента боитесь, что он что-то сломал, — и потому просите «быть осторожнее», добавляете лишние проверки и замедляете работу. Во второй вы знаете, что в любой момент можете вернуться на шаг назад одной командой, — и позволяете агенту действовать смело. Разница не в аккуратности агента, а в вашей уверенности: откат превращает ошибку из катастрофы в рутинную операцию.

  1. Смелость экспериментов. Чем дешевле откат, тем более рискованные и полезные изменения вы готовы пробовать.
  2. Чистое сравнение. Откатившись к известной точке, вы можете спокойно сравнить два варианта и выбрать лучший.
  3. Быстрое восстановление. Неудачная серия ходов не оставляет следов — вы просто возвращаетесь на последний хороший коммит.
  4. Меньше стресса. Откат — это штатный инструмент, а не признание провала. Отношение «сделал — проверил — откатил» экономит нервы и ходы.

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

Чек-поинты — ваша машина времени

Система контроля версий (обычно git) по сути является машиной времени: коммит фиксирует состояние всего проекта в конкретный момент. Каждый коммит — это чек-поинт, к которому можно вернуться.

В работе с агентом чек-поинты приобретают особый смысл. Агент меняет файлы «пачками», и без точек сохранения вы не сможете сказать, какое именно изменение привело к проблеме. Правило простое: коммитьте после каждого логически завершённого шага, который вы проверили, а не в конце дня.

  1. Один коммит — одно изменение. Так проще понять, какой шаг сломал проект, и откатить ровно его.
  2. Коммит после проверки. Сначала убедитесь, что изменение работает — тесты и diff, — потом фиксируйте.
  3. Понятное описание. «Добавил валидацию суммы» лучше, чем «правки»: через неделю вы поймёте, что было в этом коммите.
  4. Коммит перед риском. Перед крупным рефакторингом зафиксируйте текущее состояние, даже если там незавершённая работа.

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

Движение назад: три способа отката

У git есть три основных инструмента для движения назад, и путать их, мягко говоря, не желательно. Разница — в том, что именно вы откатываете: незакоммиченные правки, указатель ветки или уже сохранённый в истории коммит.

Команда Что делает
git restore Возвращает файлы рабочей директории к состоянию из индекса или из коммита. Отменяет незакоммиченные правки, не трогает историю.
git revert Создаёт новый коммит, отменяющий изменения выбранного коммита. История остаётся линейной и безопасной для команды.
git reset Перемещает указатель ветки назад. Флаги --soft, --mixed и --hard определяют, что произойдёт с файлами и индексом.

Пример использования в работе с агентом:

git status                          # что изменилось
git restore src/checkout.ts         # отменить незакоммиченные правки одного файла
git revert HEAD                     # отменить последний коммит новым коммитом
git reset --hard 8f3a11c            # жёсткий откат к конкретному коммиту

Правило выбора простое.

Если правки ещё не закоммичены — git restore. Если коммит уже сделан и вы работаете один — можно git reset. Если коммит запушен в общую ветку — только git revert, иначе вы перепишете историю и сломаете коллегам синхронизацию.

Безопасность git reset —hard

git reset --hard — самый мощный и самый опасный инструмент: он безвозвратно стирает незакоммиченные изменения и переводит проект в выбранное состояние. Применяйте его только тогда, когда точно знаете, что ничего ценного не потеряете, а лучше — когда у вас есть свежий чек-поинт.

Движение вперёд: что делать после отката

Откат — не конец работы, а поворот. Вернувшись в рабочую точку, вы идёте вперёд уже с учётом того, что не сработало. Но в неудачной попытке часто есть удачные куски, которые жалко терять, — и git позволяет их сохранить.
  1. git stash. Откладывает незакоммиченные правки в сторону, чтобы вернуться к ним позже. Удобно, когда вы хотите «убрать» эксперимент, но не удалять его окончательно.
  2. Отдельная ветка. Эксперимент ведётся в ветке, а рабочая версия остаётся в main. Не срослось — ветку удаляем, main не тронут.
  3. git cherry-pick. Переносит один конкретный коммит из другого места. Если в неудачной попытке есть удачный коммит, его можно «пересадить» в текущую ветку.
  4. Копия в файл. Самый простой способ — сохранить удачный фрагмент кода в заметку или отдельный файл до отката.

Ветки как параллельные вселенные

Ветки позволяют двигаться вперёд несколькими путями одновременно: агент экспериментирует в feature-ветке, а проверенная версия живёт в main. Если эксперимент удался — ветка вливается, если нет — просто удаляется. Это самый удобный способ пробовать подходы, не рискуя основной кодовой базой.

Как агент выполняет откаты

Откат — это тоже изменение, и агент умеет выполнять его по вашей команде. Формулируйте запрос так же, как любой другой: контекст, задача, критерий готовности.

Отмени изменение, которое ты только что сделал в src/checkout.ts.
Верни файл к состоянию до моего последнего запроса и покажи diff,
чтобы я проверил.

Важное правило: откат, выполненный агентом, вы тоже проверяете. Попросите показать diff до и после, убедитесь, что откатилось ровно то, что нужно, и только потом продолжайте. Агент не должен откатывать «втихую» — это такое же изменение, как и любое другое.

Практический сценарий цикла «сделал — проверил — откатил»

Соберём изученное в рабочий цикл, который вы можете повторять при каждой заметной задаче.

  1. Чек-поинт. Коммит текущего состояния перед началом работы.
  2. Запрос. Даёте агенту задачу с критерием готовности.
  3. Проверка. Смотрите diff, запускаете тесты, оцениваете результат.
  4. Решение. Удачно — коммитите результат. Неудачно — откатываете через restore или revert.
  5. Новый заход. Переформулируете задачу с учётом того, что не сработало, и повторяете цикл.

Перед откатом всегда смотрите, что именно изменится: git diff покажет разницу до того, как вы её уничтожите. Откат без предпросмотра — такой же риск, как изменение без предпросмотра: вы можете случайно стереть то, что хотели оставить. Одна команда git diff перед git restore избавляет от неприятных сюрпризов.

Частые ошибки при откатах

  1. Откат вслепую. Не проверили, что именно откатываете, и уничтожили удачную работу. Всегда смотрите diff до отката.
  2. git reset --hard на общей ветке. Переписанная история ломает синхронизацию у всей команды. Запушенные коммиты откатывайте только через git revert.
  3. Потеря удачных идей. Откатили всё целиком вместе с полезными кусками кода. Сначала сохраните ценное — stash, ветка, копия.
  4. Коммиты «всё в одном». Если в одном коммите десять изменений, откатить одно из них сложно. Дробите изменения на логические шаги.
  5. Откат вместо диагностики. Иногда дешевле починить конкретную проблему командой агенту, чем откатывать большой кусок работы. Сначала оцените масштаб.

Итоги

Движение во времени в проекте строится на трёх китах: чек-поинты фиксируют состояние, git restore, git revert и git reset откатывают изменения с разной степенью жёсткости, а ветки и stash позволяют сохранить полезное из неудачных попыток.

Вместе с умением формулировать команды отката агенту это превращает ошибки из проблемы в штатный шаг рабочего цикла.

В следующем уроке разберём, как агент запускает Bash-команды: какие команды он может выполнять, как выглядит его взаимодействие с оболочкой и как контролировать этот процесс.

Глоссарий

  1. Чек-поинт — зафиксированное состояние проекта, к которому можно вернуться; в git это коммит.
  2. Коммит — сохранение состояния проекта в истории системы контроля версий.
  3. git — система контроля версий, отслеживающая изменения файлов проекта.
  4. История коммитов — последовательность сохранённых состояний проекта в порядке их создания.
  5. git restore — команда отмены незакоммиченных изменений в файлах.
  6. git revert — команда отмены коммита путём создания нового обратного коммита.
  7. git reset — команда перемещения указателя ветки назад, с флагами —soft, —mixed и —hard.
  8. git stash — команда откладывания незакоммиченных правок в сторону для возврата к ним позже.
  9. git cherry-pick — команда переноса одного коммита из одной ветки или истории в другую.
  10. Ветка — независимая линия разработки, позволяющая вести эксперименты отдельно от основной версии.
  11. Рабочая директория — файлы проекта на диске в текущий момент.
  12. Индекс — промежуточная область git, куда попадают изменения перед коммитом.
  13. Diff — построчное представление изменений между двумя состояниями файлов.
  14. HEAD — указатель на текущий коммит ветки.
  15. Откат — возврат проекта или файла к предыдущему состоянию.

Теги: