Git worktree: как работать над несколькими задачами одновременно без stash

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

Что такое worktree на самом деле

По умолчанию у репозитория git есть один рабочий каталог (worktree) — папка, куда извлечено содержимое текущей ветки, и один специальный каталог .git с историей, объектами и настройками. Команда git worktree add не клонирует репозиторий заново — она создаёт ещё одну рабочую папку, которая ссылается на тот же .git, но извлекает в себя отдельную ветку. История, объекты, настройки remote — всё общее и хранится один раз. Разными остаются только файлы на диске и то, какая ветка сейчас в них извлечена.

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

Как создать и убрать worktree

Базовый сценарий — три команды. Сначала смотрим, что уже есть:

git worktree list

Дальше создаём новую рабочую папку под конкретную задачу — например, для срочного багфикса, пока основная папка занята незакоммиченной фичей:

git worktree add ../myproject-hotfix hotfix/urgent-bug

Эта команда создаст соседнюю папку myproject-hotfix, извлечёт туда ветку hotfix/urgent-bug (если её ещё нет — можно сразу добавить флаг -b, чтобы создать новую ветку от текущего HEAD) и подключит её к тому же репозиторию. Дальше это обычная папка: можно открыть в редакторе, запустить тесты, собрать проект отдельно от основной рабочей копии.

Когда задача закрыта, worktree убирается так же просто:

git worktree remove ../myproject-hotfix

Если папку удалили руками, а git всё ещё думает, что worktree существует, поможет git worktree prune — она уберёт из внутреннего списка ссылки на каталоги, которых больше нет на диске.

Где это реально экономит время

• Срочные фиксы посреди фичи. Не нужно stash'ить незакоммиченные изменения и держать в голове, что именно там лежит — фича остаётся нетронутой в своей папке.
• Параллельный код-ревью. Можно извлечь чужой PR в отдельный worktree, погонять его локально, не трогая свою текущую рабочую копию и не теряя незакоммиченный прогресс.
• Долгие тесты или сборки в фоне. Пока в одной папке крутится долгий прогон тестов на одной ветке, в другой можно спокойно продолжать писать код на другой — без ожидания и без риска зацепить те же файлы.
• Сравнение поведения двух версий. Например, старой и новой ветки одного и того же сервиса, запущенных бок о бок, чтобы визуально сверить разницу в поведении.

Worktree не заменяет ветки — он даёт каждой активной задаче собственное место на диске, чтобы переключение контекста не превращалось в ритуал со stash и надеждой, что ничего не потерялось.

На что обратить внимание

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

Во-первых, каждый worktree — это полноценная копия файлов на диске, а не облегчённая ссылка: если проект тяжёлый или в нём много зависимостей вроде node_modules, несколько worktree начнут заметно есть место на диске. Их придётся либо переустанавливать в каждой папке отдельно, либо выносить в общее место через инструменты уровня выше git.

Во-вторых, не стоит заводить worktree «про запас» на каждую мелкую задачу — если рабочих копий становится больше пяти-шести, начинает теряться смысл: вы снова тратите время, но уже на то, чтобы вспомнить, в какой из папок что происходит. Практический ориентир — держать worktree под каждую реально параллельную задачу, а не под каждую ветку, которая теоретически может понадобиться.

В-третьих, worktree — это фича самого git, а не конкретного хостинга или клиента, поэтому она одинаково доступна из терминала, но не всегда одинаково удобно показана в GUI-клиентах и интегрированных средах разработки — стоит один раз проверить, как ваш редактор отображает несколько worktree одного репозитория, прежде чем полагаться на этот рабочий процесс постоянно.

В сумме git worktree — не замена веткам и не замена stash полностью, а дополнительный инструмент для конкретной проблемы: параллельной работы над несколькими задачами в одном репозитории без постоянного переключения контекста в одной и той же папке. Если вы регулярно ловите себя на цепочке «stash → checkout → работа → checkout обратно → stash pop», это ровно тот случай, когда стоит один раз настроить worktree и забыть про эту рутину.