Параллельные сессии и worktree

1. Три разных слоя одной работы

«Ветка», «сессия», «worktree» — это не три названия одного переключения, а три разных слоя. Спутаете их — довольно быстро упрётесь в вопрос: «а я сейчас вообще где?».

Проще всего запомнить это через таблицу:

Если сказать совсем по-человечески, ветка отвечает на вопрос: в какую линию истории я сейчас пишу изменения. Сессия отвечает на вопрос: в каком разговоре Claude сейчас думает об этой задаче. Worktree отвечает на вопрос: в какой физической папке на диске у меня открыта эта работа.

Представьте, что у вас есть один большой архив документов, два рабочих стола и два разговора с коллегой. Архив — это Git. Рабочие столы — это worktree. Разговоры — это сессии Claude. Если смешать архив, стол и разговор в одно понятие, начнётся классическая разработческая комедия: «Подождите, а я сейчас где именно?»

Ветка хранит историю, сессия хранит контекст, worktree хранит отдельное рабочее место.

Из этой формулы сразу следует важный вывод. Можно создать новую ветку и вообще не открывать Claude. Можно открыть новую сессию Claude и не создавать новую ветку. Можно создать второй worktree и работать там руками без AI. Эти сущности связаны, но они не равны друг другу.

2. Ветка хранит историю, сессия хранит контекст

Здесь полезно чуть замедлиться, потому что именно на этом месте чаще всего и рождается путаница. Ветка — это чисто Git-объект. Её можно создать без всякого Claude, и Git будет совершенно счастлив.

git switch -c refund-refactor
git branch --show-current   # refund-refactor
git status                  # On branch refund-refactor

Здесь уже произошёл переход в новую линию истории проекта. Но никакой новой сессии Claude вы ещё не создали. Если сейчас открыть Claude Code, он просто увидит текущую папку и текущую ветку. Не больше и не меньше.

Сессия устроена наоборот. Это разговор, а не история. У одной и той же ветки может быть несколько разных сессий. Например, утром вы открыли сессию и попросили Claude исследовать, как в AI Commerce Growth OS устроен refund-flow. Вечером вы открыли уже другую сессию, в той же ветке, но с чистым контекстом, и попросили только проверить diff и тесты.

И тут появляется важный практический нюанс. Если вы откроете две редактирующие сессии Claude в одной и той же папке, они будут смотреть на один и тот же набор файлов. Это уже не две независимые комнаты, а два человека, которые одновременно пишут на одной доске. Формально Git от этого не ломается, но когнитивно становится очень весело. Один Claude уже переписал сервис, второй ещё думает на основе старого чтения файлов, а вы сидите между ними и чувствуете себя диспетчером маленького хаоса.

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

Точные команды переименования или возобновления сессий могут меняться от версии Claude Code. Но сама привычка не меняется: называйте сессии по задаче, а не по настроению. refund-refactor-review всегда лучше, чем условное «новая сессия 7». Иначе через пару дней у вас будет музей артефактов под названием «потом разберусь». Обычно не разбираются. Обычно страдают.

3. Worktree: вторая рабочая папка без clone

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

Вот базовый пример:

git worktree add -b hotfix/refund-amount-typo ../commerce-os-hotfix main
cd ../commerce-os-hotfix
git branch --show-current   # hotfix/refund-amount-typo
pwd                         # /projects/commerce-os-hotfix

Что произошло? Git создал рядом новую папку, завёл для неё новую ветку от main и выдал вам второй рабочий каталог. Это не полный новый clone репозитория. История Git у worktree общая с основным проектом, поэтому операция быстрая и обычно не раздувает диск так, как второй полноценный клон.

Очень полезно мысленно видеть это так:

/projects/
├── commerce-os/          # ветка refund-refactor, своя сессия Claude
└── commerce-os-hotfix/   # ветка hotfix/refund-amount-typo, своя сессия Claude

Именно здесь worktree становится мощным инструментом. У вас теперь не одна папка, которую приходится мучить stash, switch, switch back, ой, а где мои незакоммиченные изменения, а две отдельные поверхности. В одной продолжается длинный рефакторинг. В другой спокойно делается срочный hotfix.

Ещё один приятный момент: у каждой папки свои локальные build-артефакты, свои незакоммиченные изменения, свои открытые вкладки IDE, свои терминалы. Для Commerce OS, где у вас есть и Java-часть, и Next.js-часть, это особенно удобно. Вы не рискуете случайно пересобрать одно состояние поверх другого.

Git при этом пытается вас защитить. Например, одну и ту же ветку он обычно не даст держать в двух worktree одновременно:

git worktree add ../commerce-os-copy refund-refactor
# fatal: 'refund-refactor' is already checked out at '/projects/commerce-os'

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

4. Уместность worktree и риск лишнего шума

Worktree полезен ровно в тот момент, когда он убирает переключение и снижает риск. Если он нужен «потому что так делают серьёзные люди», он уже начинает мешать. Не надо превращать его в ритуал посвящения. Для большинства повседневных задач обычной ветки вполне достаточно.

Ниже — короткая карта решений:

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

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

Отдельно стоит сказать про параллельные Claude-сессии без worktree. Это выглядит заманчиво: открыл два окна, в одном просишь «проанализируй», в другом «параллельно поправь». Но если обе сессии смотрят в одну папку, физического разделения нет. В какой-то момент одна сессия читает уже изменённые файлы, вторая всё ещё рассуждает по старым данным, и вы внезапно оказываетесь в домашней версии распределённой системы без координации. Звучит красиво, живётся так себе.

Поэтому хорошее практическое правило такое: если задачам нужно одновременно иметь своё локальное состояние на диске, им нужен worktree. Если разница только в разговоре и фокусе анализа, достаточно отдельных сессий.

5. Сценарий Commerce OS: refactor + hotfix

Теперь давайте посмотрим на ситуацию, где worktree ощущается не как теория, а как способ сохранить себе нервы. Представим, что в AI Commerce Growth OS вы уже второй день ведёте рефакторинг refund-flow. У вас есть ветка refund-refactor, часть логики уже вынесена, тесты зелёные только на одном milestone, но работа ещё не закончена.

И вот в этот прекрасный момент прилетает срочная мелочь: в админке неправильно отображается сумма возврата, и поддержка просит hotfix прямо сейчас. Если делать всё в одной папке, сценарий выглядит грустно. Нужно либо коммитить недоделанный рефакторинг, либо прятать его в stash, потом переключаться на main, делать hotfix, коммитить, возвращаться, поднимать stash обратно и надеяться, что ничего не перекосилось. Такой подход работает, но очень любит тратить ваше внимание на переключение контекста вместо самой задачи.

С worktree последовательность получается спокойнее.

# в основной папке продолжается большой refactor
git branch --show-current   # refund-refactor

# рядом создаём отдельную папку под hotfix от main
git worktree add -b hotfix/refund-amount-typo ../commerce-os-hotfix main
cd ../commerce-os-hotfix
git status                  # On branch hotfix/refund-amount-typo

После этого полезно проверить, что Git действительно видит обе рабочие папки:

git worktree list
# /projects/commerce-os         a1b2c3d [refund-refactor]
# /projects/commerce-os-hotfix  e4f5a6b [hotfix/refund-amount-typo]

Дальше всё становится очень прямолинейно. В основной папке commerce-os/ остаётся ваш длинный рефакторинг и та сессия Claude, где накоплен контекст именно по refund-flow. В папке commerce-os-hotfix/ вы открываете второй терминал, вторую IDE-вкладку или вторую сессию Claude и работаете только с hotfix. Никакого stash, никакого «подождите, а это сейчас уже main или всё ещё refactor?»

Если hotfix маленький, вы быстро прогоняете нужные проверки в этой второй папке:

./gradlew test --tests "*Refund*"
# BUILD SUCCESSFUL

И дальше живёте обычной жизнью: commit, PR, merge. А ваша большая задача при этом даже не вздрогнула. Она всё ещё лежит в первой папке ровно в том состоянии, в каком вы её оставили.

Именно в таких сценариях worktree особенно хорош. Он не ускоряет сам hotfix магически. Он просто не заставляет вас платить дополнительный налог вниманием за то, что задач стало две.

6. Дисциплина параллельной работы и уборка

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

Хорошая микропривычка — первые три секунды в любом терминале тратить на короткую проверку:

pwd                       # /projects/commerce-os-hotfix
git branch --show-current # hotfix/refund-amount-typo
git status -sb            # ## hotfix/refund-amount-typo

Это выглядит почти смешно по простоте, но именно такие три команды спасают от очень глупых ошибок. Открыли терминал, посмотрели папку, посмотрели ветку, посмотрели статус. Всё. Вы уже не редактируете вслепую.

Очень помогает и нормальное именование. Папка ../commerce-os-hotfix лучше, чем ../temp2. Ветка hotfix/refund-amount-typo лучше, чем fix1. Сессия Claude по смыслу hotfix тоже должна называться как hotfix, а не «новая». Чем больше параллельных сущностей, тем важнее, чтобы их названия работали на вас.

Есть и ещё одна тонкость, о которой новички часто забывают. Worktree — это временный рабочий ресурс, а не коллекция вечных папок. После merge его нужно закрывать так же аккуратно, как вы его открывали. Не стоит просто удалять папку мышкой или rm -rf, будто ничего не произошло. Git хранит список worktree, и лучше дать именно Git корректно убрать запись.

cd ../commerce-os
git worktree remove ../commerce-os-hotfix
git branch -d hotfix/refund-amount-typo   # после merge
git worktree list                         # убеждаемся, что всё чисто

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

И ещё один спокойный, но очень важный вывод. Worktree — не медаль «теперь вы senior». Это просто инструмент файловой изоляции. Если без него проще — не используйте его. Если он спасает вас от stash-цирка, случайных переключений и двух задач в одной папке — используйте без чувства вины. Хороший Git-приём не обязан быть модным. Достаточно того, что он делает вашу работу понятнее и спокойнее.