Git worktree разделяет рабочие папки параллельных агентов, а совместимость правок проверяют отдельно

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

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

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

Представим систему заказов. Первый агент меняет признак завершённого заказа: теперь это статус «выполнен». Второй пишет отчёт и считает завершёнными заказы со старым статусом «закрыт». Они редактируют разные файлы и не мешают друг другу в папках.

Git может объединить такие правки без текстового конфликта. Он совмещает изменения файлов, но не знает, что в бизнесе считается завершённым заказом. Чистое слияние не доказывает, что новый отчёт покажет новый заказ.

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

В нашей машине vibecoding.ru агент однажды заменил слово по всему репозиторию и задел чужие зоны. В другом заходе исполнитель удалил рабочую папку соседней задачи по совпадению имени. Это ошибки границ работы: дополнительная папка сама их не запрещает.

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

Инженер ведёт машину агентов на собственном проекте; открытая история нашей машины показывает её работу. Клиентского кейса, где мы измерили эффект worktree, у нас нет. Эти поломки объясняют риски, но не доказывают процент предотвращённых ошибок.

Допустим, агент закончил задачу и показал зелёные проверки. Пока он работал, соседняя задача изменила общий код. Старый прогон подтверждает старое сочетание изменений. Он не отвечает на вопрос, что получится при объединении сейчас.

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

GitHub описывает этот принцип в очереди слияния: изменения проверяются с актуальной базовой веткой и предыдущими правками в очереди. Очередь не обязательна для каждого проекта; собрать и проверить общую версию можно другим способом. Общий порядок работы руководителя важнее названия инструмента.

Количество папок не определяет количество независимых задач. Изменение общего формата заказа и отчёт по этому заказу зависят друг от друга. Сначала согласуют формат, затем обе задачи проверяют на нём. Иначе агентам придётся угадывать решение соседа.

Разные страницы или независимые функции проще разнести по рабочим папкам. Но если обе используют одну базу для тестов, тестовые данные тоже могут мешать. Worktree отделяет файлы; инженер отдельно решает, нужны ли разные базы и настройки запуска.

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

В нашей подписке на агентную разработку тариф «Все проекты» стоит 500 000 ₽/месяц и включает три потока. На странице сервиса поток определён как одна задача в работе, следующая ждёт в очереди. Условия сверены 8 октября 2026 года; три потока не означают три агента в одной ветке.

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

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

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

1. Дайте параллельным задачам разные ветки и рабочие папки. Одни названия веток не разделяют редактируемые файлы.

2. Ограничьте работу разрешёнными файлами. Worktree не запрещает процессу перейти в соседнюю папку.

3. Проверяйте связанные задачи вместе на актуальной основной версии. Отсутствие конфликта Git не подтверждает поведение продукта.

4. Сохраняйте идентификатор проверенной версии. После изменения её состава заново проверьте затронутые сценарии.

5. Превращайте сбой в правило или проверку. Так следующий параллельный заход получает защиту от уже известной ошибки.