Если после правок ИИ-агента сайт малого бизнеса работает неправильно, сначала остановите новые изменения и выясните, что именно агент успел поменять. Затем выберите способ отката: отменить ещё не сохранённые правки, отменить отдельный коммит или вернуть предыдущую версию сайта на сервере. В статье разберём каждый случай на примере Claude Code, а также проверим, что после отката снова открываются страницы, оформляются заказы и верно отображаются цены.
Что проверить до отката, чтобы не потерять нужные изменения?
Представьте: агент правил страницу каталога, а после публикации перестала работать кнопка заказа. Желание вернуть всё назад понятно. Но за это же время сотрудник мог обновить цены, а разработчик — исправить другую ошибку. Общий откат сотрёт и их работу, если сначала не отделить изменения агента от остальных.
Начните с короткой фиксации проблемы. Запишите адрес страницы, действие, которое приводит к ошибке, и ожидаемый результат: «Нажимаю “Оформить заказ”, форма не открывается». Затем проверьте, где находится плохая версия: только на компьютере, в репозитории кода или уже на рабочем сайте. От этого зависит способ возврата.
- Попросите агента остановиться и пока не давать ему новых задач на изменение файлов. Иначе список правок продолжит расти.
- В папке проекта выполните
git statusиgit diff. Первая команда покажет изменённые файлы, вторая — содержимое правок, которые ещё не попали в коммит. - Посмотрите последние коммиты через
git log. Если агент сохранил работу в Git, найдите коммит по времени и составу файлов, а не только по его названию. - Если ошибка уже видна посетителям, сохраните текущие логи и сделайте копию доступной вам версии сайта. Она пригодится, если причину придётся разбирать после восстановления.
Отдельно проверьте, затронул ли агент базу данных: структуру таблиц, товары, цены или заказы. Возврат файлов сам по себе не отменит такие изменения. Если этого нельзя выяснить по истории работ, сначала разберите список действий агента и файлы миграций, а уже потом запускайте откат.
Как отменить правки Claude Code в Git?
Git помогает вернуть код, но команда зависит от того, успел ли агент сохранить изменения. Перед любой отменой просмотрите список файлов: если в нём есть ваша незаконченная работа, сначала сохраните её отдельно.
| Что произошло | С чего начать | Как откатывать |
|---|---|---|
| Агент изменил файлы, но коммита ещё нет | git status и git diff | Вернуть только нужные файлы через git restore -- путь/к/файлу после просмотра разницы |
| Агент создал отдельный коммит | Найти его через git log и проверить состав | Создать отменяющий коммит через git revert ХЕШ_КОММИТА |
| После правок агента появились другие коммиты | Проверить историю и зависимости между изменениями | Отменять конкретный коммит; при конфликтах разбирать файлы вручную |
| Плохая версия уже опубликована | Уточнить, какой коммит работает на сайте | Вернуть предыдущую проверенную версию через обычный процесс публикации проекта |
git restore удаляет несохранённые изменения в выбранном файле. Не запускайте его для всего проекта «на всякий случай»: вместе с ошибкой исчезнут и полезные правки. Команда git revert действует иначе — она добавляет новый коммит, который отменяет изменения старого. История остаётся видимой, поэтому коллегам проще понять, что случилось.
Если агент менял несколько файлов ради одной задачи, просмотрите их вместе. Например, правка кнопки заказа могла затронуть страницу, обработчик формы и проверку данных. Откат одного файла из этой группы иногда оставляет сайт в состоянии, которое никто не тестировал.
Как вернуть рабочую версию сайта после публикации?
Сначала выясните, откуда сайт получает код: из коммита Git, подготовленной сборки или файлов, которые кто-то загрузил на сервер вручную. Возвращайте предыдущую версию тем же способом, которым публикуете обычные обновления. Тогда у вас останется понятная история: какая версия работала, что сломалось и что вы вернули.
Если для проекта сохраняются готовые сборки, найдите последнюю версию, которую проверяли до изменений агента. Если публикация идёт из Git, подготовьте отмену в репозитории, проверьте её вне рабочего сайта и только затем публикуйте. Прямое редактирование файлов на сервере оставьте для случая, когда другого пути нет: следующая публикация кода способна перезаписать такое исправление.
Перед возвратом проверьте, не изменилась ли база данных. Допустим, новая версия кода добавила обязательное поле заказа, а агент успел создать его в базе. Старый код может продолжить работу, но это нужно проверить на тестовой копии. Если же изменения базы требуют отдельного возврата, сохраните её актуальную копию и согласуйте порядок действий с тем, кто отвечает за сайт.
После публикации откройте проблемную страницу без сохранённой копии в браузере и повторите действие, которое вы записали в начале. Затем пройдите короткий маршрут покупателя: найти товар или услугу, увидеть цену в BYN, отправить форму либо оформить заказ. Для такого контроля пригодятся отдельные инструкции: проверка доступности сайта после правок Claude Code, проверка оплаты заказа и проверка расчёта цен в BYN.
Какие ошибки мешают откатить правки без новых поломок?
- Просить агента «починить всё» до изучения изменений. Так появляются новые правки, и граница между исходной ошибкой и попытками её исправить исчезает. Сначала сохраните описание сбоя и посмотрите разницу в файлах.
- Откатывать весь проект вместо конкретной задачи. Проверьте, не были ли после неё опубликованы нужные изменения: новые цены, товары или исправления коллег.
- Считать успешный запуск сайта доказательством исправления. Главная страница открывается, а форма заказа по-прежнему не отправляется. Повторите именно то действие, на котором нашли сбой.
- Забывать о данных. Возврат кода не возвращает автоматически содержимое базы и не отменяет заказы, которые уже поступили. Такие изменения разбирайте отдельно.
- Давать агенту право самостоятельно публиковать следующую попытку исправления. Сначала попросите показать план, список файлов и результат проверки; публикацию подтвердите после просмотра.
На будущее договоритесь о простом порядке работы с ИИ-агентом: одна задача, отдельная ветка Git, просмотр изменений и проверка перед публикацией. Это не обещает, что ошибок больше не будет. Зато при следующем сбое вы увидите границы правки и сможете отменить её, не трогая остальной сайт.
Если сайт уже сломан, начните с малого: остановите новые правки, определите плохой коммит или набор файлов, затем верните предыдущую проверенную версию. После отката повторите действие, которое вызвало ошибку, и пройдите путь до заявки или заказа. Так вы проверите результат глазами клиента, а не только по сообщению агента об успешной работе.
