Как безопасно проверить патч от ИИ перед применением

Патч от ИИ может выглядеть убедительно и всё же менять не те файлы, не применяться к вашей версии проекта или добавлять лишние действия. До применения его стоит рассматривать как непроверенный входной файл. Git позволяет сначала увидеть масштаб изменений, проверить техническую применимость без записи в рабочее дерево, а затем испытать результат в отдельной временной копии проекта.

Эта инструкция рассчитана на разработчика, который получил обычный unified diff — файл с расширением .patch или .diff — и работает в Git-репозитории. Нужны Git, терминал и команды проверки самого проекта. Платный API и доступ к сервису, который создал патч, не требуются. Команды ниже не доказывают правильность кода: они разделяют проверку формата, просмотр содержания, применение в изоляции и проверку поведения.

Что подготовить до проверки

• Сохраните ответ ИИ именно как patch-файл, без пояснений до строки diff --git и после последнего изменения.
• Откройте терминал в корне нужного Git-репозитория. Команда git rev-parse --show-toplevel должна показать ожидаемую папку.
• Запишите точную версию Git командой git --version: поведение редких параметров может отличаться между версиями.
• Узнайте штатные команды проекта для тестов, линтера и сборки. Не придумывайте их по названию файлов.

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

Зафиксируйте исходное состояние

Начните с краткого статуса. Пустой вывод означает, что Git не видит изменённых и новых файлов. Если вывод есть, сохраните его и не смешивайте существующую работу с проверкой патча. Отдельный worktree ниже строится от HEAD и не переносит незакоммиченные изменения основного рабочего дерева.

git rev-parse --show-toplevel
git --version
git status --short

Не используйте git reset --hard или git clean ради «чистоты»: они могут удалить вашу работу. Если патч должен накладываться поверх незакоммиченных изменений, сначала договоритесь, какая версия является базовой. Иначе успешная проверка на HEAD не будет проверкой фактического состояния.

Посмотрите состав патча без применения

Подставьте свой путь к файлу. Параметр --stat показывает число изменённых файлов и строк, а --summary — создание, переименование и смену режима файлов. Эти команды отключают применение. После них всё равно откройте patch-файл как текст и прочитайте каждую строку diff --git, пути после --- и +++, добавленные зависимости, конфигурацию, миграции, сетевые запросы и команды сборки.

git apply --stat ~/Downloads/ai-change.patch
git apply --summary ~/Downloads/ai-change.patch

Проверьте применимость без записи

Команда git apply --check проверяет, можно ли наложить фрагменты на текущее рабочее дерево. Параметр --whitespace=error-all заставляет Git считать пробельные ошибки причиной отказа. Успешная команда обычно ничего не печатает и возвращает код 0. После неё повторите git status --short: состояние должно совпасть с исходным.

git apply --check --whitespace=error-all ~/Downloads/ai-change.patch
git status --short

Открыть крупнее

Успех --check означает только совпадение контекста и допустимость формата. Команда не оценивает алгоритм, права доступа, обратную совместимость и безопасность. Не добавляйте --unsafe-paths: стандартная защита Git отклоняет патчи, которые пытаются выйти за рабочую область. Не переходите сразу к --reject или --3way после ошибки — сначала выясните, для какого коммита и версии создан патч.

Создайте изолированный worktree

Если предварительная проверка прошла, создайте отдельное рабочее дерево с detached HEAD. Укажите новый пустой путь рядом с проектом и заранее убедитесь, что там нет нужных файлов. Worktree разделяет историю объектов с основным репозиторием, но получает отдельные HEAD, индекс и рабочие файлы. Незакоммиченные изменения из основной папки туда не копируются.

git worktree list
git worktree add --detach ../project-ai-review HEAD
cd ../project-ai-review

Название project-ai-review — пример. Если такой путь уже существует, выберите другой новый каталог; не используйте --force для обхода конфликта. Команда git worktree list после создания должна показать основную папку и новую временную копию с detached HEAD.

Примените и изучите изменение в копии

Внутри нового worktree повторите --check, затем примените патч без --index. Так изменение останется незастейдженным и будет явно видно в status и diff. Сначала проверьте список файлов и пробельные ошибки, затем прочитайте полный diff. Не ограничивайтесь статистикой.

git apply --check --whitespace=error-all ~/Downloads/ai-change.patch
git apply --whitespace=error-all ~/Downloads/ai-change.patch
git status --short
git diff --check
git diff --stat
git diff

Открыть крупнее

git diff --check ищет пробельные ошибки в уже получившихся изменениях. git status --short показывает новые и изменённые файлы. Полный git diff позволяет проверить, что результат совпадает с прочитанным патчем. Если патч добавил новый неотслеживаемый файл, обычный git diff не покажет его содержимое: найдите строку ?? в status и откройте файл отдельно.

Запустите проверки проекта с ограничениями

Запускайте только известные команды проекта: целевой тест изменённого модуля, затем линтер или проверку типов, затем более широкий набор, если риск этого требует. Зафиксируйте команду, код завершения и версию среды. Если патч меняет установочные сценарии, зависимости или сами тесты, сначала проверьте эти строки вручную. Для недоверенного кода используйте одноразовую изолированную среду без секретов; worktree сам по себе не ограничивает сеть и доступ к файлам пользователя.

1. Проверьте поведение, которое патч должен исправить, на точном воспроизводимом примере.
2. Запустите узкий существующий тест и убедитесь, что он действительно затрагивает изменённую ветку.
3. Проверьте соседний сценарий, который не должен измениться.
4. Сравните git status --short до и после тестов: генераторы могут добавить новые файлы.
5. Сохраните ошибки полностью, но удалите из отчёта секреты и персональные пути.

Как отменить эксперимент

Вернитесь в основную папку проекта и ещё раз посмотрите git worktree list. Удаление с --force стирает незакоммиченные изменения внутри указанного временного worktree, поэтому выполняйте его только для только что созданной одноразовой папки после проверки точного пути. Не подставляйте путь основной рабочей копии.

cd /путь/к/основному/проекту
git worktree list
git worktree remove --force ../project-ai-review
git worktree list
git status --short

Основной status после удаления должен совпасть с записанным в начале. Если вы решили сохранить результат, не удаляйте worktree: сначала создайте отдельную ветку, повторно проверьте diff и оформите обычный review. Положительный ответ ИИ и успешное применение патча не заменяют ревью человеком.

Типичные ошибки

• Применять патч в основной грязной рабочей папке, а затем пытаться отделить его от своих изменений.
• Считать пустой вывод git apply --check доказательством корректности программы.
• Использовать --unsafe-paths, --reject или --3way, не разобрав причину первоначального отказа.
• Запускать изменённые install-скрипты и тесты в среде с рабочими секретами.
• Смотреть только git diff --stat и пропускать содержимое новых неотслеживаемых файлов.
• Удалять временный worktree по непроверенному пути или использовать для него существующую папку.

Как понять, что проверка завершена

Проверка завершена, когда известны база патча и полный список файлов, --check проходит на нужной версии, полный результат просмотрен в отдельной копии, штатные проверки выполнены в подходящей безопасной среде, а основной репозиторий остался в прежнем состоянии. Если любой из этих пунктов неизвестен, результат следует записать как непроверенный или частично проверенный, а не как готовый к слиянию.