Страховка в одну команду: как использовать Git worktree, чтобы смело экспериментировать с большими кодовыми базами

Когда работаешь с крупным репозиторием, смена задачи ощущается и рискованной, и дорогой по времени. Вы можете быть в середине большого рефакторинга — и тут внезапно прилетает продакшн-баг. Что делать? Делать stash? Коммитить наполовину сломанный код? Ещё раз клонировать репозиторий и снова ждать длинную установку зависимостей?

Ни один из этих вариантов не радует.

Git worktree дают гораздо более удобный подход: несколько независимых рабочих директорий, опирающихся на один общий репозиторий. Одной дополнительной командой вы создаёте безопасную песочницу для экспериментов, исправления багов или ревью кода — без вмешательства в основную рабочую директорию.

В этом посте разберём, что такое worktree, почему они особенно полезны в больших проектах и как использовать их в повседневной работе.

Что такое Git worktree?

Git worktree — это дополнительная рабочая директория, «подцеплённая» к одному и тому же репозиторию .git. Обычно в каждом worktree чекаутится своя ветка, но при этом все они используют одну и ту же базу git-объектов.

На практике это означает:

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

Это принципиально отличается от повторного клонирования репозитория:

Несколько клонов = несколько директорий .git, дублированная история, повторяющиеся git fetch/git pull и зачастую продублированные зависимости.
Несколько worktree = одна директория .git и общая база объектов, плюс дешёвые дополнительные рабочие директории с собственным содержимым.

Почему worktree особенно полезны в больших проектах

В маленьких проектах постоянное переключение веток просто раздражает. В больших — может полностью ломать рабочий поток.

1. Больше не нужно бесконечно переключать ветки

С worktree вместо этого сценария:

git checkout feature-x
# работаем

# ой, срочный баг

git stash
git checkout hotfix-branch
# чиним баг

git checkout feature-x
git stash pop

вы можете сделать так:

# основная рабочая директория: feature-x

# создаём отдельный worktree под hotfix
$ git worktree add ../project-hotfix hotfix-branch
$ cd ../project-hotfix
# чиним баг здесь, независимо от основной директории

Обе ветки остаются чекаутнутыми параллельно, в разных директориях. Никакой возни со stasхами и потери контекста.

2. Больше никаких рискованных stash

Stash часто превращается в свалку полузабытых изменений. С worktree каждая линия работы живёт в настоящей директории, а не в скрытом стеке stash.

Каждый эксперимент — в своей директории worktree.
Ваша «главная» директория (обычно на main или develop) остаётся чистой и надёжной.
Не нужно вспоминать, что лежит в каком stash, и бояться git stash drop.

3. Избегаем затрат на несколько клонов

Для больших репозиториев несколько клонов — довольно болезненная история:

Лишний трафик и время на клонирование.
Дополнительное дисковое пространство под дублирующиеся .git.
Повторная установка зависимостей (например, node_modules, артефакты сборки) в каждом клоне.

Worktree решают это аккуратно:

Один репозиторий, одно хранилище .git.
Дополнительные worktree в основном добавляют файлы рабочего каталога, а не ещё одну копию истории Git.
Делаете fetch один раз — используете одни и те же коммиты в нескольких директориях.

4. Более безопасные эксперименты

Хотите попробовать рискованный рефакторинг, новую toolchain или накидать прототип?

Создаёте новый worktree.
Основная рабочая директория остаётся стабильной и «продакшн-гарантированной».
Если эксперимент никуда не привёл — можно удалить всю директорию одним махом.

В больших проектах, где пересборки, миграции и изменения в инструментах дороги по времени, модель «отдельная песочница под каждую идею» невероятно удобна.

Первые шаги: базовые команды worktree

Вся магия крутится вокруг команды git worktree.

1. Список существующих worktree

git worktree list

Вы увидите что-то вроде:

/path/to/project           abc1234 [main]
/path/to/project-feature   def5678 [feature/cool-idea]
/path/to/project-bugfix    9ab0123 [bugfix/login]

Каждая строка — это worktree: путь, текущий коммит и ветка.

2. Создание нового worktree

Общий шаблон:

git worktree add <path> <branch-or-commit>

Типичные сценарии:

Начать новую фичу от main:

$ cd /path/to/project
$ git fetch origin
$ git worktree add ../project-new-feature origin/main
$ cd ../project-new-feature
$ git switch -c feature/new-api

Вытащить существующую ветку в новую директорию:
```
$ git worktree add ../project-bugfix bugfix/1234
```
Поработать с конкретным коммитом или тегом:
```
$ git worktree add ../project-old-release v1.2.0
```

Теперь у вас есть новая директория со своим git status, git log и локальными изменениями — полностью независимая от других worktree.

3. Удаление worktree

Когда с каким-то worktree вы закончили:

# из любой директории этого репозитория
$ git worktree list
# находим путь, который хотим удалить

$ git worktree remove /full/path/to/worktree

Это безопаснее, чем просто rm -rf, потому что:

Git корректно очищает внутренние ссылки на этот worktree.
Вы не оставляете «залежавшихся» записей, которые будут мешаться в git worktree list.

Совет: перед удалением worktree всегда закоммитьте или куда-то сохраните всё, что вам важно. Удаление worktree удаляет и его рабочую директорию.

Практический дневной workflow с worktree

Вот как можно организовать день с использованием worktree в большом проекте.

1. Держите стабильный «домашний» worktree

Используйте изначальный клон как домашнюю базу, обычно на main или develop:

/path/to/project   # всегда на main или develop

Здесь вы подтягиваете последние изменения.
Запускаете быстрые проверки, читаете код, делаете «безопасные» операции.
Не начинаете рискованные задачи прямо в этой директории.

2. Один worktree на каждую значимую задачу

Для каждой крупной задачи создавайте отдельный worktree:

# фичи
/path/to/project-feature-x
/path/to/project-feature-y

# хотфикс
/path/to/project-hotfix-123

Плюсы:

В каждой директории свои сборки, логи и настройки IDE.
Можно открыть несколько окон IDE бок о бок, каждое привязано к своей ветке.

Пример:

$ cd /path/to/project
$ git fetch origin
$ git worktree add ../project-feature-x origin/main
$ cd ../project-feature-x
$ git switch -c feature/x

3. Как переживать прерывания и переключения контекста

Когда появляется срочная задача:

Не трогайте директорию с текущей фичей.

Из домашнего worktree создайте отдельную директорию под фикc:

$ cd /path/to/project
$ git fetch origin
$ git worktree add ../project-critical-fix origin/main
$ cd ../project-critical-fix
$ git switch -c hotfix/critical-issue

Чините, тестируйте, пушьте, открывайте PR из этого worktree.

Когда всё закончено:

$ git worktree remove ../project-critical-fix

Ваша фича-директория за всё это время осталась нетронутой. Никаких stash, конфликтных git checkout и наполовину применённых изменений.

4. Регулярная уборка старых worktree

Со временем директории worktree будут копиться. Периодически:

$ git worktree list
# выбираем те, что уже не нужны
$ git worktree remove ../project-feature-you-finished

Если после git worktree remove Git не удалит директорию целиком (например, из-за защищённых файлов), можно вручную добить её rm -rf.

Советы, лучшие практики и подводные камни

Совет 1: Давайте директориям понятные имена

Используйте осмысленные имена, чтобы по ним сразу было понятно, что где:

project-main
project-feature-payments
project-bugfix-login-timeout

Это особенно помогает, когда у вас открыто несколько окон IDE и терминалов.

Совет 2: Следите за артефактами сборки

Worktree разделяют историю Git, но не артефакты сборки. Обычно это плюс, но:

В очень больших проектах повторные установки/сборки в каждом worktree могут быть дорогими.
Если инструменты поддерживают кэши (например, глобальный кэш node_modules, кэш сборки), имеет смысл настроить их совместное использование.

Совет 3: Не чекаутьте одну и ту же ветку в нескольких worktree

По умолчанию Git не позволит одной и той же ветке быть чекаутнутой сразу в нескольких worktree — и это правильно:

Так вы избегаете путаницы, когда одну и ту же ветку меняют в разных директориях.
Если очень нужно, можно завести отдельные вспомогательные ветки под каждый worktree (feature/x-spike, feature/x-refactor) и потом слить их.

Совет 4: Используйте worktree для код-ревью и `git bisect`

Пара распространённых продвинутых сценариев:

Код-ревью: чекаут ветки PR в отдельный worktree, чтобы локально прогнать всё, не трогая основную работу.
Bisect: запуск git bisect в отдельном worktree, чтобы основная директория не зарастала временными чекаутами.

Совет 5: Освойте минимальный набор команд

Не нужно сразу запоминать всё. Начните с:

git worktree list
git worktree add ../path branch
git worktree remove ../path

Этого уже достаточно, чтобы ощутить заметный прирост удобства.

Итоги: удобная страховка, которой вы будете реально пользоваться

Git worktree — небольшая по объёму, но очень мощная функциональность, особенно для больших, тяжело собираемых, критичных для бизнеса проектов. Они дают вам:

Несколько параллельных рабочих окружений без множества клонов репозитория.
Изолированные эксперименты без опасных stash.
Быструю смену контекста без акробатики с ветками.

Большинство команд ограничиваются git checkout и git stash, но как только вы начинаете использовать worktree, возникает вопрос — как вообще раньше без них обходились.

В следующий раз, когда вы соберётесь застешить недоделанные изменения или в очередной раз клонировать репозиторий, остановитесь и попробуйте вместо этого:

cd /path/to/your/project

git worktree add ../project-new-task origin/main
cd ../project-new-task

Эта одна команда может стать вашей новой страховкой для смелых экспериментов.