Вы правите экспорт отчётов, а coding agent исправляет авторизацию в том же каталоге. Такой агент читает код, меняет файлы и запускает проверки по вашей задаче. Теперь git diff показывает изменения обоих. Трудно понять, какие файлы уже заняты вашей работой, а какие можно передать агенту.

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

Что именно создаёт worktree

Обычно у репозитория один рабочий каталог: в нём лежат файлы выбранной ветки. Команда git worktree add добавляет ещё один каталог к тому же репозиторию. У нового каталога свои файлы, выбранная ветка и индекс Git - список изменений, подготовленных к коммиту. История коммитов и ветки остаются общими.

В чём отличие от обычной ветки? Ветка - указатель на коммит, а worktree даёт отдельный каталог, в котором с этой веткой можно работать. Если создать ветку и переключиться на неё через git switch, файлы в текущем каталоге сменятся. Если создать worktree, исходный каталог останется на месте, а новая ветка откроется в соседнем. Поэтому для одновременной работы человека и агента нужны и ветки, и отдельные рабочие каталоги.

Например, вы можете держать незавершённый рефакторинг в основном каталоге, а срочную правку сделать в соседнем. Не придётся прятать текущие файлы через git stash и затем восстанавливать их. Git приводит именно такой случай в документации worktree.

Как дать агенту отдельную задачу

Допустим, основной проект лежит в ~/code/project, а в нём выбрана ветка main. Из этого каталога создайте worktree и новую ветку. Если в проекте другая базовая ветка, подставьте её вместо main.

git worktree add -b agent/login-fix ../project-login-fix main
git worktree list

Новый каталог окажется рядом с основным: ~/code/project-login-fix. Git не требует именно такого расположения: путь может вести и в отдельный каталог для временных worktree. Соседний каталог - простой вариант для начала; такой путь использует пример в документации Git. Если работаете в IntelliJ IDEA, JetBrains советует не размещать worktree внутри проекта: IDE может принять их за несколько корней одного проекта.

Затем запустите coding agent из каталога ../project-login-fix или выберите этот каталог при создании задачи. Попросите исправить конкретный сценарий, запустить подходящие тесты и показать результат. Для другой независимой задачи создайте ещё один worktree со своей веткой. Некоторые приложения делают это при запуске агента; например, такую возможность описывает документация GitHub Copilot app.

Когда агент закончит, откройте его каталог и проверьте результат:

cd ../project-login-fix
git status
git diff

Запустите тесты для этой задачи и сохраните нужные изменения коммитом в ветке agent/login-fix. Если git status ещё показывает изменённые файлы, они не попадут в обычное объединение веток.

Как перенести результат в main

Worktree не меняет способ объединения. Ветка агента уже видна из основного каталога: оба каталога используют один репозиторий. Копировать файлы не нужно. Когда закончите работу в основном каталоге и git status там будет чист, вернитесь в него и выполните обычный merge:

cd ../project
git diff main...agent/login-fix
git merge agent/login-fix

Первая команда показывает изменения ветки агента относительно общего исходного коммита. Вторая объединяет её с main. Если main с тех пор не менялась, Git просто передвинет её указатель на новый коммит. Если ветки разошлись, Git объединит изменения и при необходимости попросит разрешить конфликт. Это обычный merge веток.

Если команда принимает изменения через pull request, отправьте ветку agent/login-fix на сервер и откройте PR в main. Это особенно удобно, пока ваша работа в основном каталоге ещё не закончена: локально объединять ветки в этот момент не требуется. После объединения снова запустите важные тесты уже на итоговом коде.

После показанного локального merge, когда в каталоге агента не осталось нужных локальных файлов, удалите worktree, а затем ветку:

git worktree remove ../project-login-fix
git branch -d agent/login-fix

Это два разных действия: git worktree remove удаляет рабочий каталог, а git branch -d удаляет локальную ветку после обычного merge. Если PR объединили через squash, сначала обновите локальную main. Git может не считать исходную ветку объединённой и откажется выполнять branch -d; проверьте результат перед удалением ветки.

Git не даст обычной командой удалить worktree с незакоммиченными или неотслеживаемыми файлами. Игнорируемые файлы, например локальные настройки, при удалении каталога тоже исчезнут, поэтому сначала проверьте, нужно ли их сохранить.

Где граница пользы

Worktree разделяет файлы и индексы Git. Он не разрешает конфликты между двумя ветками, если агенты меняют один и тот же участок кода: при объединении изменений их всё равно придётся разобрать. Поэтому при параллельной работе полезно заранее назначить каждому агенту задачу и ветку, а после работы записать, какие проверки он выполнил. Такой порядок предлагает руководство Warp. Локальные базы данных, занятые порты и другие внешние ресурсы тоже нужно разделять отдельно.

Незакоммиченные файлы из основного каталога не появляются в новом worktree. Игнорируемые файлы, включая зависимости и .env, тоже не копируются автоматически. Если они нужны для тестов, настройте среду в новом каталоге и выдайте агенту только необходимые данные. Об этом отдельно предупреждает руководство VS Code по агентам. Сам worktree не ограничивает доступ процесса к другим каталогам и секретам: для этого нужны настройки среды выполнения.

Правило простое: одна независимая задача - отдельная ветка и отдельный worktree. После работы проверьте diff и тесты, объедините изменения и уберите лишний каталог.

Комментарии в Telegram-группе!