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

Ви запускаєте два агенти на одному репозиторії. Один редагує package.json, інший робить те ж саме. Через тридцять секунд ваш код у стані, який ніхто не може змерджити.

Це не помилка у ваших агентах. Проблема в тому, що вони всі працюють в одній папці.

Рішенням є інструмент, який Git має вже багато років, але майже ніхто не використовує: git worktree.

Проблема: 3 агенти, 1 репозиторій, неможливий мердж

Звичайний Git репозиторій: це одна папка з однією гілкою, яка перевіряється одночасно. Ви працюєте на main, перемикаєтеся між гілками, і вся папка змінюється.

Тепер додайте три автономні агенти в цю папку. Вони пишуть одночасно. Агент A створює файл, агент B запускає git checkout, щоб почати з чистого аркуша, і видаляє роботу A в процесі. Ви отримуєте наполовину написані файли, зіпсований індекс і конфлікти, які займають більше часу на розв'язання, ніж якби ви самі це закодували.

Паралелізм економить ваш час лише якщо агенти не заважають один одному.

Що таке git worktree

Worktree: це друга робоча папка, прикріплена до того ж репозиторію.

Та ж історія, той же віддалений репозиторій, але кожен 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

Кожен агент має свою папку, свою гілку, свої файли. Агент аутентифікації ніколи не побачить, що робить агент білінгу. Ніяких можливих зіткнень.

Коли функція готова, ви переглядаєте її гілку і змерджуєте. Потім ви очищуєте:

git worktree remove ../project-auth

Папка зникає, гілка залишається в вашій історії. Чисто.

3 пастки, які потрібно знати

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

Друга: гілки, які відстають. Поки ваші агенти працюють, main рухається далі. Через три дні ваші гілки відстають, і мердж стає болючим. Перебазуйтеся рано і часто, або тримайте сесії короткими.

Третя: забуте очищення. Кожен 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 лише через цей скрипт, інакше на третьому агенті ви про все це забудете.

Якщо ви не хочете підтримувати цей скрипт, менеджер worktree в AgentsRoom і є інструментом, який робить це за вас: один worktree на тікет або на агента, підготовлений до старту агента, а потім переглянутий, закомічений і змерджений у тому самому вікні.

Справжнє питання: хто стежить за п'ятьма папками?

Worktrees вирішують проблеми зіткнень файлів. Вони не вирішують вашого ментального навантаження.

У вас є п'ять папок, п'ять агентів, п'ять терміналів. Який з них чекає на ваш огляд? Який закінчив десять хвилин тому, поки ви дивилися в інший бік? Який з них зламався?

Ось де один worktree на агента досягає своєї межі, якщо ви залишаєтеся в терміналі. Ви вирішили технічний конфлікт, але збільшили кількість вікон для спостереження.

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

Що взяти з собою

Один агент, один worktree, одна гілка. Це базове правило серйозної багатоагентної роботи з агентами.

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