# Параллельные чаты и рабочие деревья Если ты уже смешарик со стажем, освоился с Git, ветками и коммитами, вот следующий эксперимент: поручить разным чатам разные задачи в одном проекте. Для первого знакомства этот бонус можно пропустить. Если пробуешь — ниже есть готовая памятка, чтобы не собирать правила с нуля. Допустим, один агент делает интерфейс, другой исправляет выбор цели у врагов. Если оба правят одну папку, они могут перезаписать чужие изменения или проверить смесь двух незавершённых задач. **Ветка хранит историю изменений, а рабочее дерево — worktree — даёт отдельную папку с файлами проекта.** Поэтому для параллельной работы удобно использовать их вместе. В Codex при создании нового чата выбери **«Рабочее дерево»** и укажи исходную ветку. Для этого проект должен быть репозиторием Git. Начинай от согласованной версии проекта; если приложение предлагает перенести текущие незакоммиченные правки, сначала проверь, чьи они и нужны ли в этой задаче. Порядок действий описан в [официальной документации](https://learn.chatgpt.com/docs/environments/git-worktrees). У рабочих деревьев отдельные файлы, но общая история Git. Изменения не появляются в основном проекте сами собой — их нужно принять и объединить. Worktree также не разделяет автоматически уже открытый редактор, внешние сервисы или общую базу данных. ## Исполнители делают задачи, главный собирает результат Мне подошла такая схема: каждый рабочий чат делает и проверяет свою задачу в отдельной ветке `codex/название-задачи`. А отдельный главный чат проверяет готовые результаты, объединяет их по очереди и проверяет весь проект. Кто главный и на какой объём работы — решаю я. Новый чат не получает эту роль автоматически. Заранее распределяй не только темы, но и файлы. «Ты делаешь интерфейс, а ты — логику» не поможет, если обоим понадобился один и тот же общий класс. Такие пересечения нужно согласовать до правок. Сначала попробуй две небольшие независимые задачи. Codex может создать дерево в режиме **detached HEAD** — на конкретном коммите, пока без именованной ветки. Для этой схемы попроси создать там ветку `codex/...` от согласованного коммита. Выбор актуальной базы важен: старое дерево может отстать от основного проекта. Обновлять его нужно отдельно, сохраняя свою работу. На одном компьютере исполнителям необязательно делать push: главный видит их коммиты через общий репозиторий. Для работы на разных машинах результат нужно передать через удалённый репозиторий или согласованный патч. Завершение задачи само по себе не разрешает публикацию. ## Готовые правила для `AGENTS.md` Ниже — памятка для этой схемы. Здесь основная ветка называется `main`: **замени её на свою**, например `master`. Правила можно добавить к существующему `AGENTS.md`; сначала проверь, не противоречат ли они договорённостям проекта. ```md ## Параллельные чаты и ветки - По умолчанию чат — исполнитель. Главным его назначает владелец явно, на оговорённый объём. Новые чаты это назначение не наследуют. - Один исполнитель — одна задача, своё рабочее дерево и ветка codex/... Перед правками проверь корень проекта и git status --short --branch. Из detached HEAD создай ветку от согласованного коммита main либо заданной базы. Чужие незакоммиченные правки не переноси. - Исполнитель меняет только своё дерево и порученные файлы. Не меняет основную папку, main и чужие ветки; не сливает туда результат и не делает Handoff в основную папку. Обновления базы переносит только в свою ветку, сохраняя свою работу. - После необходимых проверок исполнитель самостоятельно делает коммиты своей задачи, добавляя явные пути. Не использует git add . или git add -A. Чужие правки, AGENTS.md и .agents/ не меняет и не коммитит без отдельного поручения. Push и публикация — отдельно. - Сдаёт ветку, исходный коммит, итоговый HEAD, список изменений, результаты проверок, ограничения и риски. После сдачи не дописывает ветку без нового поручения. - Главный проверяет результат и объединяет принятые изменения по очереди. После объединения проверяет общий проект. Не убирает и не коммитит чужие правки. При пересечении файлов откладывает объединение и согласовывает порядок работ. - Перед правками через редактор или MCP проверь открытый проект: он должен принадлежать своему дереву. Для Unreal проверь .uproject; Binaries, Intermediate и Saved держи раздельно. Один бинарный ассет одновременно поручай одному исполнителю. - Перед работой проверь корневые и вложенные AGENTS.md и нужные навыки .agents/skills. Копии локальных инструкций в ранее созданных деревьях нужно обновлять отдельно. - Внешние относительные пути из локальных инструкций разрешай относительно исходного проекта, определённого через git worktree list. Код, ассеты и проверки — относительно своего дерева. Это не разрешает правки внешних проектов. ``` Разрешение на коммиты здесь записано специально: исполнитель сохраняет только свою задачу. Если правила и навыки хранятся в Git, их согласованные обновления тоже можно коммитить отдельной задачей. Запрет выше защищает их от попутных правок. ## Чтобы инструкции приехали вместе с деревом В моём Unreal-проекте обнаружился нюанс: `AGENTS.md` и навыки были локальными, исключёнными из Git. Новое дерево получило код, а эти правила — нет. Для таких файлов в Codex есть **`.worktreeinclude`**: положи его в корень репозитория и перечисли нужные игнорируемые пути. Например: ```gitignore # Только если эти файлы исключены из Git AGENTS.md **/AGENTS.md .agents/skills/** !**/__pycache__/** !**/*.pyc ``` Если инструкции ссылаются на другие локальные файлы, добавь и их конкретные пути. Сам `.worktreeinclude` удобно сохранить в Git. Отслеживаемые файлы уже приходят из выбранного коммита — их в этот список добавлять не нужно. Просто неотслеживаемые файлы, которые не исключены из Git, этим способом не копируются. Копирование работает при создании локального дерева, управляемого приложением Codex. Для уже созданных деревьев это не постоянная синхронизация; для дерева, созданного вручную командой Git, перенос нужно организовать отдельно. Подробнее — в [разделе о локальных файлах](https://learn.chatgpt.com/docs/environments/git-worktrees#copy-ignored-local-files-into-managed-worktrees). Для Unreal есть ещё одна проверка: перед управлением редактором выясни, какой `.uproject` открыт. Два чата могут оказаться в разных деревьях и всё равно управлять одним Unreal Editor. Не давай им одновременно менять один Blueprint, `.uasset` или `.umap`: это бинарные файлы, обычное текстовое слияние для них не подходит. [Epic объясняет эту особенность работы с ассетами](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-perforce-as-source-control-for-unreal-engine). ## Два поручения для первой пробы Рабочему чату: > Ты исполнитель. Прочитай `AGENTS.md`, проверь свою папку, ветку и исходный коммит. Задача: [результат]. Разрешённые файлы: [пути]. База: [коммит]. Работай в своём дереве и ветке `codex/[название]`. После проверок закоммить только эту задачу и передай отчёт. Не меняй основную папку, не сливай результат в основную ветку и не делай туда Handoff. Если нужен чужой файл или не хватает инструкции, останови зависимую работу и назови причину. Главному чату: > На эту интеграцию ты главный. Прочитай `AGENTS.md`. Проверь результат ветки `codex/[название]` относительно базы [коммит]: соответствие задаче, diff, проверки и ограничения. Если результат подходит и нет пересечений с чужой незавершённой работой, объедини его с [основная ветка] и проверь общий проект. При конфликте не выбирай чужую версию наугад — объясни, что нужно согласовать. Push и публикацию этим поручением не разрешаю. В отчёте исполнителя достаточно такого набора: ```text Задача и разрешённые файлы: Рабочая папка и ветка: Исходный коммит и итоговый HEAD: Что изменено: Проверки и результаты: Что не проверено, блокеры и риски: ``` Удачный результат — не просто две готовые ветки. Главный принял их по очереди, общий проект работает, а чужие правки сохранились. Эту памятку можно забрать в свой проект уже сейчас; подробную работу с harness разберём в отдельном курсе. Источник: https://gamepunk.ru/academy/ai-intro/03-project-agent Проверено: 2026-10-02.