Git worktree: параллельная разработка без головной боли
Parallel development without the headaches using Git worktree
Автор делится личным опытом использования git worktree — функции Git, позволяющей работать над несколькими ветками одновременно, каждая в своей директории, но с общей историей. Рассказывает, как это упрощает переключение между фичами и срочными хотфиксами, приводит практические примеры создания, слияния и удаления worktree, а также очистки устаревших записей. Советует использовать worktree для параллельных задач, оставляя традиционное ветвление для последовательной работы.
Он держит все элементы в отдельных отсеках, сокращает переключение контекста и делает stash редким исключением.
- tlarkworthy
Я использую мета-репозиторий верхнего уровня, чтобы создать виртуальный монорепозиторий из всех моих репозиториев и подключить их апстримы, а затем использую worktree'ы от сабмодулей для подготовки патчей. Мне никогда не нужно менять директорию из корневого мета-репозитория, даже с несколькими агентами. Это дает полный опыт монорепозитория, не владея ни одной из его частей, и каждый агент имеет свой изолированный worktree, поэтому конфликтов нет.
- zmmmmm
Настоящая проблема параллельной разработки — обеспечить, чтобы параллельные среды разработки могли сосуществовать, не наступая друг другу на пятки. Как только одна из них хочет открыть порт, подключиться к внешней базе данных или записать в общее место в рамках тестирования, они начинают конфликтовать. Во многом это проблема легаси-разработки, где изначально не предполагалось, что параллельные эфемерные среды разработки будут задействованы. Но легаси-разработка по-прежнему составляет большую часть разработки.
- therealmarv
Может, я упрям, но даже в эпоху ИИ я по-прежнему использую несколько клонов/директорий одного проекта, например:
~/dev/projectx
~/dev/projectx2
~/dev/projectx3
~/dev/projectx4
Очень редко использую более 4–5 на проект. Может, я просто избегаю разбираться с worktree'ами и пробовать их.
Преимущества: эти клоны служат полупостоянными директориями:
- Помогает с кэшированием при интенсивном использовании Docker (подумайте о повторяющихся параллельных unit- и e2e-тестах)
- Я раскрасил вкладки терминала для каждого клона, чтобы сразу видеть, где я нахожусь (что-то вроде групп вкладок, только с цветами)
Может, если по какой-то причине мне понадобятся десятки клонов проекта, я буду вынужден использовать git worktree, потому что тогда будет раздражать запоминать, в какой директории живет клон ветки.
- irskep
Я пользуюсь git worktree ежедневно. Меня удивляет, как сложно бывает объяснить их людям, которые никогда ими не пользовались. В последнее время я остановился на сравнении: «как клоны, но с общей .git директорией». Статья пытается донести это, сравнивая с ветками, но я думаю, что клоны — более интуитивное понятие для сравнения.
Чтобы решить некоторые проблемы эргономики (многословность команд, ручные команды для копирования .env файлов и установки зависимостей), я написал autowt — легковесный, но мощный менеджер worktree: https://steveasleep.com/autowt/
Как только я настроил интерфейс командной строки, я практически перестал печатать 'git checkout <branch>' для смены задач, потому что проще игнорировать состояние рабочей директории при переключении между задачами.
- pkghost
Проведя около месяца в кроличьей норе worktree, я сдаюсь в пользу множественных checkout'ов, чтобы позволить многим агентам работать в разных репозиториях.
Worktree'ы отлично работали, когда работа моих агентов была в основном ограничена одним репозиторием (они позволили мне наконец достичь лимитов скорости, хотя это и не было целью). По мере роста моего homelab агенты все чаще работают в нескольких репозиториях, и именно здесь (мой подход к) worktree'ам сломался; агенты порождались в worktree репозитория и поэтому не наступали на пятки другим агентам в том же репозитории без специальных инструкций, но как только им нужно было затронуть другой репозиторий, они по умолчанию работали в этом репозитории напрямую, без worktree, и таким образом сталкивались с другими агентами, а также засоряли процесс слияния, который ожидал, что основной клон репозитория будет чистым (что оказалось ненужной особенностью дизайна, но ее решение все равно не помешало бы агентам наступать друг другу на пятки во вторичных репозиториях).
После отклонения в сторону ZFS dataset клонов и некоторых магических монтирований, которые делали /srv/src/ отдельной иерархией для каждого агента, я упрощаю еще больше и даю каждому агенту отдельную директорию (что-то вроде /srv/dev/<slug>/), где они могут checkout'ить любые репозитории. Git remote (/srv/git/) становится единственной точкой интеграции.
Может, мне стоит просто решиться и перейти на контейнеры, но, несмотря на их производительность, эргономика все еще расстраивает.
Редактирую: возможно, я все же оставлю ZFS dataset'ы с mou…