Git Worktrees + Claude Code: параллельная разработка без боли

Представьте ситуацию: вы запускаете Claude Code, чтобы он написал новую фичу авторизации. Пока он работает, прилетает баг в проде. Вы открываете второй терминал, просите Claude пофиксить баг... и всё ломается. Два агента правят одни и те же файлы, конфликтуют, затирают изменения друг друга. Знакомо?

В феврале 2026 года в Claude Code завезли нативную поддержку git worktrees, и это, пожалуй, самый мощный апгрейд для тех, кто запускает несколько сессий параллельно. Разберёмся, как это работает и почему команда Anthropic называет worktrees «главным productivity-хаком».

Git worktree - это отдельная рабочая директория, привязанная к тому же репозиторию. У каждого worktree своя ветка, свои файлы, но общая история коммитов и remote-подключения.

Проще говоря: вместо одной папки с проектом у вас появляется несколько «клонов», которые не мешают друг другу. Но при этом это не полноценные клоны - они делят между собой .git, так что не нужно скачивать репозиторий заново.

Важно: worktrees существуют в Git давно, но раньше настраивать их для Claude Code приходилось вручную. Теперь всё работает одним флагом.

Самый простой способ - запустить Claude Code с флагом --worktree (или -w):

Что происходит под капотом:

Вот и всё. Два агента, два терминала, ноль конфликтов.

Допустим, у вас утро понедельника и три задачи в бэклоге. Раньше вы бы делали их последовательно. Теперь:

Терминал 1 - новая фича:

claude --worktree feature-payments > "Реализуй интеграцию с платёжным шлюзом Stripe по спецификации в docs/payments.md"

Терминал 2 - багфикс:

claude --worktree bugfix-memory-leak > "В сервисе UserService есть утечка памяти при обработке WebSocket-соединений. Найди и исправь"

Терминал 3 - рефакторинг:

claude --worktree refactor-api-v2 > "Отрефактори REST API контроллеры, вынеси валидацию в middleware"

Каждый Claude работает изолированно: правит свои файлы, делает свои коммиты, не подозревая о существовании соседей.

Devhack: Борис Черни из команды Anthropic рекомендует запускать 3-5 worktrees одновременно. Некоторые разработчики из команды Claude Code настраивают shell-алиасы (za, zb, zc) чтобы переключаться между worktrees одним нажатием клавиши. Отдельный лайфхак - держать один «аналитический» worktree только для чтения логов и запросов к базе данных.

А вот здесь начинается магия. Мало того что вы можете запустить несколько Claude-сессий в разных worktrees - сами субагенты внутри одной сессии тоже могут работать в изолированных worktrees.

Это особенно полезно для масштабных миграций и batch-изменений. Например:

> "Обнови все 15 микросервисов на новую версию SDK. Используй worktrees для своих агентов"

Claude порождает субагентов, каждый из которых получает свой worktree и обновляет свой микросервис. Когда субагент завершает работу без изменений, его worktree автоматически удаляется.

Можно пойти ещё дальше и прописать это поведение в кастомном агенте через frontmatter:

--- isolation: worktree --- Ты агент для миграции зависимостей. Обнови package.json и исправь breaking changes.

После этого агент всегда будет создавать себе worktree автоматически. Не нужно просить об этом каждый раз.

Один из приятных моментов - Claude Code сам разбирается с уборкой:

Внимание: добавьте .claude/worktrees/ в .gitignore, чтобы содержимое worktrees не отображалось как untracked files в основном репозитории. Это не критично, но сильно снижает «шум» в git status.

echo ".claude/worktrees/" >> .gitignore

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

Самый прямолинейный путь. Переходим в основной worktree (он же корневая директория проекта) и мержим:

Важно: ветка из worktree, созданного через claude --worktree feature-auth, будет называться worktree-feature-auth. Claude добавляет префикс worktree- автоматически.

На практике чаще всего вы захотите не мержить напрямую, а создать PR. Это даёт код-ревью, CI/CD проверки и вообще нормальный рабочий процесс:

Или можно попросить Claude сделать это прямо из сессии:

> "Запуши изменения и создай Pull Request в main с описанием того, что было сделано"

Claude запушит ветку и (если настроен gh CLI) создаст PR с описанием.

Иногда из worktree нужна не вся работа, а конкретные коммиты. Например, Claude сделал пять коммитов, а вам нужны только два:

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

Сценарий: Claude в worktree-feature-auth добавил middleware аутентификации в server.ts, а Claude в worktree-refactor-api переписал структуру роутера в том же файле.

git merge worktree-feature-auth # Auto-merging src/server.ts # CONFLICT (content): Merge conflict in src/server.ts # Automatic merge failed; fix conflicts and then commit the result.

Дальше есть два пути.

Разрулить вручную:

Попросить Claude помочь:

Claude посмотрит на конфликтные маркеры, поймёт контекст обеих сторон и предложит решение. Это, кстати, один из случаев, когда AI-ассистент реально экономит время - разрешение конфликтов в чужом коде бывает мучительным делом.

Devhack: Чтобы минимизировать конфликты, старайтесь разносить задачи по разным частям кодовой базы. Если один Claude работает над авторизацией, а второй над платежами - шансы на конфликт минимальны. Проблемы начинаются, когда оба агента лезут в общие файлы типа package.json, конфигурации или shared-утилиты.

Мержить такие worktrees лучше последовательно: слили первый, подтянули main во второй, потом слили второй.

Такой подход проще, потому что конфликты решаются по одному, а не все разом. А если использовать PR-flow, то вообще красота: слили первый PR, CI прошёл, потом ребейзнули второй - и в нём уже видно, ломается что-то или нет.

Флаг --worktree покрывает 90% случаев, но иногда нужно больше контроля. Например, разместить worktree в конкретной директории или привязать к существующей ветке:

Важно: в каждом новом worktree нужно заново инициализировать окружение. Это значит npm install, активация виртуального окружения Python, или что там требует ваш стек. Зависимости не шарятся между worktrees.

«Почему npm install занимает так долго в каждом worktree?»

Потому что node_modules не расшаривается. Это можно частично решить, используя pnpm с его store - он хранит пакеты централизованно и создаёт хардлинки. Или просто смириться: worktrees экономят время на переключении контекста, а npm install можно пережить.

«Случайно удалил worktree с несохранёнными изменениями»

Если вы использовали --worktree, Claude предупредит перед удалением. Но при ручном управлении через git worktree remove --force - всё, данные потеряны. Коммитьте чаще.

«Хочу использовать worktrees, но у нас Mercurial/SVN»

Для не-git систем контроля версий можно настроить хуки WorktreeCreate и WorktreeRemove с кастомной логикой создания и очистки worktrees. Эти хуки заменят дефолтное git-поведение при использовании --worktree.

Worktrees с Claude Code - это не просто удобная фича, а изменение всего подхода к работе. Вместо «одна задача за раз» появляется «три-пять задач параллельно».

Когда это особенно полезно:

Попробуйте начать с двух worktrees и посмотрите, как это ощущается. Скорее всего, через неделю три-четыре параллельных сессии станут нормой.

Документация по git worktrees в Claude Code: docs.claude.com Официальная документация Git worktree: git-scm.com/docs/git-worktree