Паралельні сесії та 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-прийом не зобовʼязаний бути модним. Достатньо того, що він робить вашу роботу зрозумілішою та спокійнішою.