Git worktree: як одночасно працювати з кількома гілками без повторного клонування

git worktree додає кілька робочих каталогів до одного repository, спільно використовуючи object database. Це зручно для термінового hotfix, паралельного review або довгого build: кожен каталог має власний index і checked-out branch без постійного stash та checkout.

Одна branch зазвичай зайнята одним worktree

Git не дозволяє звичайно checkout тієї самої branch у двох місцях, щоб паралельні зміни не створили плутанину. Для review використовують detached HEAD або окрему local branch. Path і branch видно через git worktree list.

Спільними залишаються objects і refs

Fetch, новий commit і tag доступні всім worktrees, але untracked files, index та working tree окремі. Це економить disk порівняно з clone, хоча build artifacts і dependencies у кожному каталозі можуть займати багато місця.

Environment не копіюється автоматично

Файл .env, virtual environment, node_modules, generated config і IDE settings можуть бути прив’язані до path. Bootstrap script має створювати локальний стан без копіювання секретів. Ports і database names розділяють, якщо два worktrees запускаються одночасно.

Видаляти каталог вручну недостатньо

git worktree remove коректно прибирає реєстрацію, а prune очищає stale administrative records після втрати каталогу. Locked worktree захищає removable drive або тимчасово недоступний path від prune. Перед remove перевіряють uncommitted changes.

Автоматизація має використовувати унікальні paths

CI або agent може створювати worktree для task, але branch name, directory та cleanup повинні бути deterministic і без injection. Один process не видаляє worktree, де працює інший. Регулярна перевірка знаходить abandoned каталоги та старі branches.

Що контролювати на практиці

Після впровадження варто відстежувати кількість active і stale worktrees, disk use, cleanup failures, branch collisions і bootstrap time. Показники порівнюють у тому самому сценарії, на тих самих пристроях або даних і з відомою версією налаштувань. Для критичних відхилень заздалегідь визначають безпечну дію та відповідального. Рішення переглядають, коли змінюється repository layout, build system, environment bootstrap, CI agent або cleanup policy. Такий журнал допомагає відрізнити реальне покращення від випадкової зміни умов.

Практичний чекліст

• перевірити git worktree list
• створювати окрему branch
• автоматизувати bootstrap environment
• видаляти через git worktree remove
• очищати stale записи командою prune

Висновок

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

Першоджерела: Git worktree documentation.