Git worktrees: основа для запуска нескольких AI-агентов без конфликтов

Ты запускаешь двух агентов на одном репозитории. Один правит package.json, второй тоже. Через тридцать секунд код в таком состоянии, что слить его уже невозможно.

Это не баг твоих агентов. Просто все они работают в одной общей папке.

Решение есть в Git уже много лет, и почти никто им не пользуется: git worktree.

Проблема: 3 агента, 1 репозиторий, слить нельзя

Обычный Git-репозиторий, это одна папка, в которой в каждый момент времени активна только одна ветка. Ты работаешь на main, переключаешь ветку, и вся папка переключается целиком.

А теперь запусти в эту папку трёх автономных агентов. Они пишут одновременно. Агент A создаёт файл, агент B запускает git checkout, чтобы начать с чистого листа, и сносит всё, что A не успел сохранить. В итоге у тебя наполовину записанные файлы, разломанный индекс и конфликты, разбираться с которыми дольше, чем если бы ты написал всё сам.

Параллелизм экономит время только тогда, когда агенты не лезут друг к другу.

Что такое git worktree

Worktree, это вторая рабочая папка, привязанная к тому же репозиторию.

Та же история, тот же remote, но в каждом worktree активна своя ветка и лежат свои файлы на диске. Можно держать пять штук рядом, каждый на своей ветке, и они не будут мешать друг другу.

Один .git, несколько рабочих пространств. Вот и всё.

По одному worktree на агента, на практике

Вот как это настроить. Из своего репозитория:

git worktree add ../project-auth -b feature/auth
git worktree add ../project-billing -b feature/billing
git worktree add ../project-export -b feature/export

Ты только что создал три папки, каждую на своей ветке. В каждой запускаешь агента:

cd ../project-auth && claude
cd ../project-billing && codex

У каждого агента своя папка, своя ветка, свои файлы. Агент auth никогда не увидит, что делает агент billing. Столкновение исключено.

Когда фича готова, ты проверяешь её ветку и сливаешь. Потом подчищаешь:

git worktree remove ../project-auth

Папка исчезла, ветка осталась в истории. Чисто.

3 ловушки, о которых надо знать

Первая ловушка, общий центральный файл. Если двум фичам приходится трогать один и тот же routes.ts или одну и ту же схему базы, worktrees тебя не спасут: конфликт ты получишь при слиянии. Если один агент правит файлы, общие для всех, остальные либо ждут, либо ищут обходные пути.

Вторая, ветки расходятся. Пока агенты работают, main уезжает вперёд. Через три дня твои ветки отстали, и слияние превращается в боль. Делай rebase почаще или держи сессии короткими.

Третья, забытая уборка. Каждый worktree, это настоящая папка на диске. Десять штук в день без уборки, и родительская папка превращается в свалку. git worktree list показывает, что валяется, git worktree prune убирает мёртвое.

Четвёртая ловушка: worktree стартует пустым

Worktree содержит только файлы, которые отслеживает Git. git worktree add даёт тебе исходный код, но не node_modules, не .venv, не .env с твоими локальными секретами и не кэш сборки. Агент, который стартует в свежем worktree, не может запустить тесты, не может поднять dev-сервер и часто не говорит почему: npm test падает на отсутствующем модуле, приложение падает на отсутствующей переменной окружения, и агент тратит первые десять минут на возню с окружением, а не на тикет.

На этом мы обожглись сами. Один пользователь указал, что опция worktree в AgentsRoom была спрятана в расширенных параметрах формы агента и что любой агент, запущенный в worktree, оставался без единой зависимости и не мог прогнать ни одного теста. И то и другое было правдой. Изоляция существовала, но пользоваться ей было нельзя без ручного шага, о котором никто не помнил.

Начиная с версии 1.194.0 опция стоит в блоке «Изоляция» формы агента, видна без раскрытия чего-либо, а первый агент, запущенный в свежем worktree, получает его уже подготовленным: AgentsRoom копирует из основной рабочей копии игнорируемые файлы, подходящие под шаблон (по умолчанию все .env*, никогда ничего не перезаписывая и никогда не в node_modules или .git), затем запускает команду установки, определённую по lockfile (bun, pnpm, yarn, npm, uv, poetry, pipenv, bundle, composer), или ту, что ты задал в настройках проекта. Команда выполняется в собственном терминале агента, так что ты её видишь, а неудачная установка не мешает агенту стартовать. Это происходит один раз на worktree: метка в приватной git-папке worktree гарантирует, что следующий запуск этот шаг пропустит.

Если делаешь это руками, рецепт тот же и умещается в скрипт: скопировать .env*, запустить установку, потом запустить агента. Вызывай git worktree add только через этот скрипт, иначе на третьем агенте забудешь про всё это.

Главный вопрос: кто следит за пятью папками?

Worktrees решают проблему столкновения файлов. Они не решают проблему твоей нагрузки на голову.

У тебя пять папок, пять агентов, пять терминалов. Какой из них ждёт твоего ревью? Какой закончил десять минут назад, пока ты смотрел в другую сторону? Какой упал?

Вот тут по одному worktree на агента упирается в потолок, если ты остаёшься в терминале. Технический конфликт ты решил, но размножил окна, за которыми надо следить.

AgentsRoom выводит каждого агента на свою плитку, с его статусом и цветом, в каком бы worktree он ни работал. Агент, который ждёт, становится красным и пингует тебя. Прочитай как запускать от 3 до 8 агентов параллельно и не терять их из виду, чтобы получить полный метод поверх worktrees.

Что стоит запомнить

Один агент, один worktree, одна ветка. Это базовое правило серьёзной работы с несколькими агентами.

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