Эффективная работа с git worktree
Если вы уже дошли до точки, когда параллельные агентские сессии как не в себя делают фичи, то вы точно должны были столкнуться с новыми проблемами, среди которых одновременный запуск нескольких копий приложений, быстро забивающийся диск и оперативная память, плюс работа которая встает колом из-за одновременных запусков тестов и линтеров. В этом посте я расскажу про то, как поправить свой сетап, чтобы все стало снова летать.
Сначала быстрый рекап. Worktree это фича гита, которая создает под ветки отдельные физические директории в которых можно вести работу. Раньше этой фичей почти не пользовались, так как просто переключались на ветку, сейчас же переключение на ветку будет сбивать параллельные сессии, поэтому все перешли на worktree. Даже если вы этого явно не просите, агенты нередко сами пользуются ими (но не всегда). И так поехали, проблемы и их решения.
Отказ от веток
Если вы пошли по этому пути, то лучше явно описать агенту, что ветки использовать нельзя, а вместо них нужно создавать worktree. Иначе регулярно будет возникать ситуация, когда один из агентов прыгнет на ветку и помешает другим.
Начало и завершение работы
По умолчанию создание worktee просто копирует данные, но в таком виде проект врядли заработает и на нем можно будет прогонять тесты. Скорее всего есть какие-то подготовительные шаги от установки зависимостей до создания .env. Вот эту часть нужно сначала автоматизировать, например, с помощью make-команд, а потом уже зафиксировать в доках с агентом, чтобы он вызывал их как при создании рабочего дерева, так и при завершении работы. У себя я считаю завершением это отправку pr, в это время происходит чистка.
Независимые базы данных
Помните проблему миграций в ветках? Вот здесь будет тоже самое, если не создавать отдельные базы данных под каждое дерево. Сделать это просто, достаточно объяснить агенту задачу и он сам предложит способ формирования динамического имени, связанного с названием worktree. Дальше снова автоматизируем и добавляем в команду создания worktree из предыдущего шага.
При этом важно сделать так чтобы это были именно базы данных, а не субд, иначе если на каждое дерево будет подниматься свой postgresql, вы быстрее начнете упираться в производительность
Одновременные запуск приложения
Кроме баз, такой же трюк надо провернуть с портами (и если используется dns то доменами). Каждое дерево при старте тестов или приложения должно работать со своим набором портов. Опять же, эту задачу сделает сам агент, он без проблем напишет небольшие скрипты, которые находят свободные порты и подсовывают их при старте приложения
Параллельный запуск проверок
Но даже если сделать все шаги выше, все равно запуск тестов или линтеров из двух worktree, уже может поставить колом всю машину. Здесь есть красивый выход через блокировку. Нужно запускать проверки не напрямую, а через утилиту, которая ставит такие блокировки и упорядочивает запуск (с нужным уровнем параллельности). Пока я этим занимался написал такую утилитку
https://github.com/mokevnin/heavy
Шаринг данных
Ну и последнее, установка зависимостей и кеши. Если вы не хотите чтобы место на диске улетало со скоростью ветра, то нужно использовать инструменты или настраивать существующие так, чтобы они шарили (безопасно) все свои артефакты во внешних директориях. Например лучше работать с pnpm, а не npm, потому что первый хранит зависимости во внешнем сторадже, что очень сокращает потребляемое место.
Если все это сделать, то работать с worktree станет реально удобно и быстро. Пользуйтесь 🙂
Telegram |
YouTube |
ИИ для разработчиков 
