Git как страховка: ветки, коммиты, откат

Агент может за минуту поменять десять файлов. Это прекрасно, когда изменения правильные, и неприятно, когда нет. Git превращает любую попытку агента в эксперимент, который можно откатить одной командой. В этом уроке — минимальная дисциплина, которая позволяет давать агенту свободу и ничего не терять.

Перед началом: чистое дерево и ветка

Первое правило: агент начинает работу на чистом рабочем дереве в отдельной ветке.

git status                            # нет незакоммиченных изменений
git switch main && git pull
git switch -c task-1234-utm-crm

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

Отдельная ветка на задачу даёт две вещи: изменения агента изолированы от основной линии, и по имени ветки понятно, что в ней. Если в команде принято называть ветки по ID задачи из трекера — следуйте этому и с агентом.

Коммиты как контрольные точки

Работайте шагами, и после каждого рабочего шага — коммит. Например, задача «передавать UTM-метки в CRM»:

1. Агент добавил чтение меток и тесты — тесты зелёные — коммит.
2. Агент изменил формат запроса к CRM — тесты зелёные — коммит.
3. Агент взялся за рефакторинг соседнего класса и всё сломал — откат к шагу 2.

Без промежуточных коммитов шаг 3 пришлось бы распутывать вручную, отделяя хорошие правки от плохих. С коммитами — одна команда.

Не бойтесь мелких коммитов в рабочей ветке: перед MR их можно объединить, если в команде так принято.

Смотреть изменения

Прежде чем коммитить, смотрите, что изменилось. Внутри сессии Codex:

/diff

Команда показывает git diff — и проиндексированные, и непроиндексированные изменения, и новые файлы, которые git ещё не отслеживает. Последнее важно: агент часто создаёт новые файлы (тесты, миграции, вспомогательные классы), и обычный git diff их не покажет.

В терминале то же самое:

git status              # какие файлы изменены и созданы
git diff                # изменения в отслеживаемых файлах
git add -p              # добавить в коммит по кускам, читая каждый

Для второго мнения есть /review — отдельный ревьюер проверит изменения и выдаст замечания, ничего не меняя. Подробно — урок «Ревью кода командой /review».

Откат

Самые нужные команды, от мягких к жёстким:

git restore path/to/file.php          # вернуть файл к последнему коммиту
git restore .                         # вернуть все отслеживаемые файлы
git clean -n                          # ПОКАЗАТЬ, какие неотслеживаемые файлы будут удалены
git clean -fd                         # удалить их (только после -n!)
git reset --hard HEAD~1               # отменить последний коммит вместе с изменениями

Две предосторожности:

• git clean -fd удаляет неотслеживаемые файлы безвозвратно, в том числе ваши, если они не в .gitignore. Всегда сначала -n.
• git reset --hard теряет незакоммиченные изменения. Если сомневаетесь — сначала git stash, потом откат: из stash можно вернуть.

Помните из урока «Сессии»: возврат к раннему сообщению в Codex (двойной Esc) меняет историю разговора, но не файлы. Откат файлов — всегда через git.

Кто коммитит

На старте коммитьте сами: так вы точно читаете каждое изменение перед тем, как оно попадёт в историю.

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

Правила оформления коммитов запишите в AGENTS.md, чтобы агент им следовал:

## Git
- Ветка на задачу: `task-<ID задачи>` от `main`
- Сообщение коммита: `task-<ID> | что сделано и зачем`, по-русски
- Не делать `git push`, `git rebase` и `git reset --hard` без явной просьбы
- Не коммитить `.env`, дампы баз и файлы из `storage/`

Что остаётся за человеком

Есть действия, которые меняют общий мир, а не вашу рабочую копию: git push, слияние в main, force-push, удаление веток на сервере. Их делаете вы — или агент только по вашей явной просьбе и после одобрения. Агент не должен работать прямо в main и не должен пушить туда.

Когда освоитесь с настройками, такие команды можно закрепить правилами, которые всегда требуют одобрения или запрещены, — урок «Rules».

И ещё раз о режиме полного доступа (--yolo): в нём песочница не защищает .git, и агент может выполнить любые команды git без спроса. На рабочем репозитории с настроенным доступом к серверу это прямой путь к случайному push. Полный доступ — только в изолированном окружении (урок «Песочница и одобрения»).

Параллельная работа: worktree

Когда захочется вести две задачи одновременно — например, агент чинит баг, а вы в это время смотрите другую ветку, — обычная рабочая копия станет тесной: два процесса начнут менять одни и те же файлы. Для этого есть git worktree — несколько рабочих копий одного репозитория в разных каталогах. Codex умеет создавать их сам: флаг --worktree при запуске или команда /worktree в сессии. Это тема урока «Несколько задач параллельно».