Git worktree и rebase: продвинутые приёмы

Ситуация знакомая: в основной ветке идёт большая переделка API, а через час нужно выпустить срочную правку в продакшен. Классический путь — git stash, переключение ветки, потом обратно и разбор конфликтов в незакоммиченных файлах. Git worktree решает задачу иначе: один репозиторий, несколько рабочих каталогов, каждый на своей ветке. Вместе с осознанным rebase это даёт аккуратный поток без гонки за одним рабочим деревом.

Что такое worktree и чем он не является

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

Ключевое ограничение: одну и ту же ветку нельзя одновременно выдать двум worktree. Git не даст переключиться на занятую ветку, и это правильно — иначе два процесса правили бы один индекс. Для экспериментальных сборок берут detached HEAD или новую ветку. Второй нюанс: worktree не копирует незакоммиченные изменения и не заменяет отдельный клон, если нужен совершенно другой репозиторий.

Параллельная работа без stash

Самый частый сценарий — срочная правка на фоне незавершённой задачи. Создаём рядом каталог с новой веткой от main, работаем там, а основное дерево не трогаем.

git worktree add ../shop-hotfix -b hotfix/checkout main
cd ../shop-hotfix
git status --short --branch
git commit -am "checkout: fix rounding" && git push -u origin hotfix/checkout

Каталог можно держать внутри проекта или рядом — главное, чтобы он не попадал в сборку и не индексировался. Если положить его внутрь рабочего дерева, добавьте путь в .gitignore, иначе Git увидит вложенный репозиторий как мусор. Для проверки релиза удобно брать detached HEAD на теге.

git worktree add --detach ../shop-v1.4.0 v1.4.0
cd ../shop-v1.4.0
make test

Такой каталог не занимает ветку и не мешает основной работе. Удалять его нужно той же командой, что и обычный worktree, иначе останется запись в служебном каталоге. Если тег переехал, старый каталог всё равно смотрит на прежний коммит — это ожидаемо и полезно для воспроизводимых сборок.

Управление и уборка

Список показывает путь, коммит и ветку. Флаг —porcelain удобен для скриптов, а prune убирает записи о каталогах, удалённых вручную.

git worktree list
git worktree remove ../shop-hotfix
git worktree prune --dry-run
git worktree lock ../release --reason "сборка до пятницы"

remove откажется удалять каталог с изменениями — это защита, а не ошибка. Сначала закоммитьте или перенесите правки, затем повторите. lock пригодится для долгих сборок и съёмных дисков: он запрещает автоматическую уборку. Не удаляйте каталоги worktree через файловый менеджер: запись останется, и prune понадобится вручную.

Rebase: когда он уместен

Rebase переносит коммиты ветки на новую базу, создавая новые объекты с другими хешами. Это удобно для личной ветки перед слиянием: история становится линейной, а ревью читается по шагам. Правило простое: не переписывайте историю, которую уже забрали другие. Общая ветка, релизный тег и main — не место для force push.

Перед любой переписывающей операцией сделайте страховку. Ветка-копия стоит копейки и спасает вечер.

git switch feature/api
git branch feature/api-backup
git fetch origin
git rebase origin/main

Если конфликт разрешён неверно, выручает git rebase —abort, а после завершения — git reflog, где виден прежний хеш. Reflog хранится локально и не заменяет резервную копию на сервере. Отдельно проверьте, что в ветке нет случайных merge-коммитов: они усложняют перенос и часто появляются после git pull без —rebase.

Interactive rebase и autosquash

Интерактивный режим позволяет переставить, объединить и переписать коммиты. Вместо ручного выбора fixup удобно помечать правки заранее.

git commit --fixup=3f2a1c9
git rebase -i --autosquash origin/main
git rebase -i HEAD~5

В редакторе строки с pick можно менять на reword, edit, squash и drop. Fixup-коммиты автоматически встают на место и схлопываются с целевым. Если редактор не настроен, задайте его явно: git config core.editor «nano». Перед rebase убедитесь, что рабочее дерево чистое, иначе Git попросит спрятать изменения. Не объединяйте в один коммит правки из разных логических шагов: ревью станет тяжелее, а откат — грубее.

Цепочки веток и —update-refs

При работе стопкой веток rebase нижней ветки оставляет верхние на старых коммитах. Опция —update-refs автоматически двигает связанные ветки, если они указывают на переписываемые коммиты.

git rebase --update-refs origin/main
git log --graph --oneline --decorate -15

Опция появилась в Git 2.38 и доступна в актуальных дистрибутивах. Она не трогает ветки, которые не входят в переписываемый диапазон, и не заменяет проверку графа. После операции сверьтесь с git log: если верхняя ветка осталась на месте, её нужно перебазировать отдельно. Для стопки из трёх-четырёх веток полезно заранее нарисовать схему зависимостей.

Конфликты, rerere и прогон тестов

Повторяющиеся конфликты при частых rebase раздражают. Механизм rerere запоминает разрешения и применяет их в следующий раз.

git config --global rerere.enabled true
git rebase --exec 'pytest -q' origin/main
git rebase --continue

Флаг —exec запускает команду после каждого коммита и останавливает процесс на первом падении. Это дешёвый способ поймать сломанный промежуточный коммит, который иначе всплывёт при bisect. Для длинных прогонов добавьте —no-verify, если хуки дублируют проверку, но не отключайте тесты насовсем. Если тест падает из-за окружения, исправьте причину, а не историю.

Опасные места и чек-лист

• Не делайте rebase опубликованной ветки без согласования с командой.
• Перед rebase создайте резервную ветку и проверьте git status.
• После force push предупредите коллег: у них разойдётся история.
• Удаляйте worktree штатно, иначе останутся служебные записи.
• Не храните в worktree секреты и локальные .env вне .gitignore.

Ещё одна привычка: не запускайте rebase на каталоге, который одновременно собирается в CI. Переписывание меняет файлы под работающим процессом, и сборка получает смесь версий. Для фоновых задач берите отдельный worktree или клон. Отдельный каталог пригодится и для экспериментов с зависимостями.

Итог

Worktree убирает необходимость прятать работу ради срочной правки, а rebase приводит личную ветку в читаемый вид. Связка особенно полезна в проектах с ревью и релизами: один каталог для задачи, второй для хотфикса, третий для проверки тега. Дисциплина проста — резервная ветка перед переписыванием, чистый статус, тесты после каждого коммита и никакого force push в общие ветки.