Git worktree: два завдання у двох робочих теках

Ви робите довідник локалей разом із Claude Code: пишете пошук у списку, роботу зроблено наполовину. І тут з'ясовується, що в збереженій версії сторінки неправильний підпис під заголовком. Виправлення на дві хвилини, але перевіряти його хочеться окремо від недоробленого пошуку, а не впереміш із ним.

Розберемо, як дати другому завданню власну робочу теку в тому самому репозиторії, відкрити в ній окрему сесію Claude Code і наприкінці зберегти результат, нічого не переплутавши. Сама по собі друга тека нічого не пришвидшує. Вона потрібна лише для того, щоб два завдання не змішалися в одному наборі файлів. І все.

Коли однієї робочої теки замало

Навчальний проєкт locale-guide - це сторінка в браузері зі списком локалей. Зараз у його теці в роботі завдання A: пошук, гілка feature/search, одна незавершена правка:

git status --short
 M app.js

Втрачати цю правку не можна, а вважати її готовим результатом зарано. І тут з'являється завдання B, ніяк не пов'язане з пошуком: виправити підпис в index.html у тій версії, яку збережено в main.

Перше, що спадає на думку, - відкрити другий термінал і запустити там ще один claude у тій самій теці. Розмови вийдуть різні, а от файли в них ті самі, тобто одна тека на двох. Якщо обидва виконавці почнуть змінювати ті самі ділянки, правки можуть змішатися. У нашому простому прикладі підпис і пошук поки що лежать у різних файлах, але обидві сесії бачать спільний незавершений проєкт. Перемикання гілки теж вимагає спершу розібратися з поточними змінами.

Вихід - дати завданню B власне робоче місце. У Git для цього є окрема робоча тека того самого репозиторію, worktree, а в Claude Code - прапорець --worktree, який готує таку теку і відразу запускає в ній сесію. Розберемо спочатку механізм, потім прапорець.

Один репозиторій, кілька робочих тек, кожна має свою гілку. Імена на рисунку довільні; у нашому прикладі дві робочі теки і три гілки: main, feature/search і fix/label.

Одразу застереження: це не обов'язковий спосіб працювати над будь-яким завданням. Якщо дерево чисте, а правка коротка, друга тека лише додасть мороки. Чергувати завдання в одній теці теж цілком нормально.

Гілка, робоча тека і сесія

Три речі, які легко переплутати, бо ви часто працюєте з ними одночасно:

Звідси й відповідь на запитання про другий термінал: нова сесія розділяє розмову, але не файли. Щоб розділилися файли, потрібна друга робоча тека.

Історія і гілки спільні: обидві теки пов'язані з одним репозиторієм. Налаштування Git за замовчуванням теж спільні, хоча Git підтримує окремі налаштування для worktree. А от робочі файли і підготовлені до коміту зміни в кожній теці свої. Незакомічений пошук із першої теки сам у другій не з'явиться.

Одну й ту саму гілку у двох теках одночасно зазвичай не відкрити - Git відмовить і назве теку, яка її вже займає:

fatal: 'fix/label' is already used by worktree at '/projects/locale-guide-label'

Виберіть вихідний стан

У навчальному прикладі репозиторій уже створено, є хоча б один коміт, локальна гілка main і гілка feature/search. Обидві поки що вказують на один коміт, а пошук існує тільки як незакомічена правка. Подивимося на вихідний стан трьома командами в основній теці:

git status --short        # що не збережено саме зараз
git branch --show-current # на якій гілці основна тека
git log -1 --oneline main # останній коміт у main

 M app.js
feature/search
d5ec405 add locale guide page

Для незалежного виправлення підпису беремо main: завданню B потрібна збережена версія сторінки, а не поточний стан пошуку. Зверніть увагу, що це локальна main на вашому комп'ютері. Вона не зобов'язана збігатися з однойменною гілкою в мережі, і команда нічого з мережі не підтягує.

Якщо другому завданню потрібен результат першого, спершу визначтеся, який збережений коміт йому потрібен, і створюйте теку від нього. Звичайний git worktree add не переносить незакомічені правки автоматично. Окреме копіювання файлів чи додаткові засоби підготовки середовища - це вже інша історія.

Створіть другу робочу теку

З теки locale-guide:

git worktree add -b fix/label ../locale-guide-label main

Читається зліва направо: створити нову гілку fix/label, покласти робочу теку поруч за шляхом ../locale-guide-label, а точкою відліку взяти main. Останній аргумент робить вибір бази явним. Без нього в цій команді Git візьме поточний коміт HEAD гілки feature/search, але не незакомічені зміни. У нашому прикладі гілки ще на одному коміті, тому файли вийшли б однаковими; після комітів із пошуком вибір бази вже вплине на результат. Git відповідає приблизно так:

Preparing worktree (new branch 'fix/label')
HEAD is now at d5ec405 add locale guide page

Далі перевіряємо, що вийшло. Прапорець -C каже Git виконати команду у вказаній теці, не переходячи в неї:

git worktree list
git -C ../locale-guide-label branch --show-current
git -C ../locale-guide-label status --short

Навчальний вивід з умовними шляхами, у вас вони будуть свої:

/projects/locale-guide        d5ec405 [feature/search]
/projects/locale-guide-label  d5ec405 [fix/label]

fix/label

Список показує обидві теки й гілку кожної з них. Основна лишилася на feature/search з незавершеним пошуком, нова стоїть на fix/label. А status у другій теці не надрукував нічого - вона чиста, і саме цього ми й домагалися.

Якщо шлях чи ім'я гілки використати не можна, Git відмовить і пояснить причину, наприклад already exists або is already used by worktree. Перевірте список worktree, гілки і вміст указаної теки. Це може бути ваш же попередній запуск або інше завдання. Не додавайте --force навмання: спершу з'ясуйте, що вже існує і чи воно потрібне.

Відкрийте друге завдання в Claude Code

Відкрийте locale-guide-label в окремому вікні IDE або просто перейдіть у неї в новому терміналі й запустіть claude звідти. Нова сесія нічого не знає про завдання A, і це нормально - контекст їй потрібен тільки свій:

Очікувана тека: locale-guide-label, гілка: fix/label.
Спочатку перевір фактичну теку і гілку. Якщо вони інші, зупинись.
Прочитай index.html.
Заміни підпис під заголовком на "Список локалей: код, мова і країна".
Більше нічого у файлі не змінюй і покажи мені зміну.

Після правки перевірте git status і git diff у кожному з двох терміналів: у другій теці змінено тільки підпис в index.html, у першій збереглася попередня правка app.js. Сам лише status показує імена файлів, але не доводить, що їхній вміст уцілів. Для точного порівняння на час перевірки призупиніть роботу над пошуком. Основну теку перевіряйте з її терміналу, не доручайте агентові з ізольованої сесії переходити туди. Сторінку відкривайте саме з другої теки, інакше побачите старий підпис (і ще хвилину гадатимете, чому правка не спрацювала).

Є й коротший шлях. Команда claude --worktree label-fix сама створює робочу теку і запускає в ній сесію. За поточною документацією тека з'являється всередині репозиторію, у .claude/worktrees/label-fix/, гілка отримує ім'я worktree-label-fix, а базою слугує гілка за замовчуванням на віддаленому репозиторії (зазвичай main), а не ваш поточний коміт. Якщо віддалений репозиторій не налаштовано, базою стане поточний локальний коміт. Тобто це не те саме, що явно вказана main у команді вище, хоча в простому проєкті результат часто збігається. Типову поведінку можна змінити в налаштуваннях, деталі варто звіряти з документацією вашої версії.

Прапорець зручний, коли база вас влаштовує і треба швидко виділити окреме місце для завдання. Виконувати його поверх уже створеної теки не потрібно: вийде ще одна. І .claude/worktrees/ варто додати в .gitignore, інакше вміст нових тек почне виринати в основній як невідстежувані файли.

Що лишається спільним

Окрема тека розділяє менше, ніж здається на перший погляд:

Третя колонка - головне, про що тут забувають. Worktree - це про файли Git, а не про ізоляцію машини. Два локальні сервери на одному порту не вживуться, і запити обох тек підуть до однієї й тієї самої зовнішньої бази, якщо її вказано в налаштуваннях. Перевірки, які Claude Code робить під час роботи в окремій теці, теж не перетворюють її на пісочницю для всієї системи.

Друга тека отримує файли вибраного коміту. Якщо залежності й локальні налаштування не зберігаються в Git, середовище зазвичай треба підготувати окремо; додаткові засоби можуть цю підготовку автоматизувати. Копіювати .env наосліп не варто: однакові облікові дані можуть спрямувати обидва запуски в один сервіс. Нашому статичному довіднику, на щастя, ні сервер, ні секрети не потрібні - сторінка відкривається як файл.

Збережіть і перенесіть результат

У теці B перевірте підпис у браузері, перегляньте git diff і зафіксуйте тільки потрібний файл:

git add index.html
git diff --cached
git commit -m "fix: correct locale list label"

Перед комітом переконайтеся, що підготовлено тільки потрібну правку. Якщо в git diff --cached є інші зміни, спершу розберіться з ними.

Коміт потрапив у спільний репозиторій, і з основної теки його вже видно. Але сам собою він не опинився ні в main, ні в feature/search. Лежить собі у своїй гілці й чекає, коли ви вирішите його об'єднати.

Переносити результат варто лише тоді, коли завдання A завершене або хоча б збережене, а основна тека чиста. Посеред незавершеного пошуку перемикатися на main не треба - спершу розберіться з ним. Коли основна тека чиста:

git checkout main
git merge fix/label

Fast-forward
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Такий вивід відповідає випадку, коли main не змінювалася після створення fix/label. Якщо Git повідомить про конфлікт, зупиніться й розберіть його за правилами злиття - це окрема тема, її розібрано в статті "Гілки і злиття в Git". Після об'єднання відкрийте сторінку ще раз: підпис має бути новим, а список локалей - таким, як раніше. Гілка feature/search від цього не оновилася: перед тим як продовжити пошук, окремо вирішіть, чи потрібно перенести в неї виправлення з main.

Приберіть непотрібну теку

Спочатку закрийте в другій теці сесію і все, що ви там запускали. Потім подивіться, чи не лишилося в ній чогось потрібного:

git -C ../locale-guide-label status --short --ignored

Змінені й нові файли видно одразу, ігноровані показує прапорець --ignored - у них нерідко лежать якраз локальні налаштування і нотатки. Переконалися, що результат збережено в потрібній гілці, - видаляйте теку з основної:

git worktree remove ../locale-guide-label
git worktree list

Якщо в теці є змінені відстежувані або нові неігноровані файли, Git зазвичай відмовиться її видаляти:

fatal: '../locale-guide-label' contains modified or untracked files, use --force to delete it

Пораду з повідомлення не варто виконувати першою ж дією. Перевірте файли і збережіть потрібне. Після видалення незакомічені дані засобами Git можна вже не відновити. На відмову як на повний захист розраховувати не можна: ігноровані файли можуть видалитися й без --force, тому ми перевіряли їх окремо.

І ще одна деталь, на якій легко помилитися. Команда Git видаляє робочу теку, але не гілку - fix/label після неї лишиться в списку git branch. Це зручно: результат нікуди не подівся. Коли гілка справді більше не потрібна і все потрібне з неї об'єднано, видаліть її окремою дією.

Видаляти теку в обхід Git, через провідник, не варто: репозиторій і далі вважатиме її наявною, і в списку worktree лишиться запис про те, чого вже немає.

Як вести друге завдання в Claude Code

Якщо стиснути все до шпаргалки, вийде шість кроків:

1. назвіть друге завдання окремо від першого і вирішіть, від якого збереженого стану його починати;
2. створіть робочу теку з явною базою або запустіть claude --worktree, якщо типова поведінка вас влаштовує;
3. перевірте в новій теці шлях і гілку, перш ніж щось змінювати;
4. дайте сесії контекст тільки цього завдання, без історії сусіднього;
5. перевірте правку там само, де її зробили, і зафіксуйте результат;
6. вирішіть питання об'єднання, і тільки потім прибирайте теку.

Окрема тека не перевіряє код і не приймає роботу за вас. Вона дає кожному завданню власні робочі файли. Користь видно в нашому прикладі: підпис виправлено й перевірено окремо, а незавершений пошук лишився в першій теці.

Перевірте себе

У другій теці немає незакоміченого пошуку. Щось пішло не так?
Ні, так і задумано. Теку створено від коміту в main, а не від поточних файлів завдання A. Незакомічені правки лишаються у своїй теці.

Дві сесії відкрито в одній теці. Завдання розділені?
Розділені розмови, а файли спільні. Зміни можуть змішатися, якщо завдання зачеплять ті самі ділянки.

Коміт у гілці B зроблено, але в main підпису немає.
Так і має бути: коміт лежить у своїй гілці. Інших гілок він не змінює, для цього потрібне об'єднання.

Другий локальний сервер не запускається на тому самому порту.
Окрема тека портів не розділяє. запускайте на іншому порту.

Git відмовився видаляти робочу теку.
Прочитайте причину відмови: окрім незбережених файлів, тека може бути заблокована або виявитися основною робочою текою. Збережіть потрібне і розберіться зі станом. Не додавайте --force навмання.

Якщо хочеться потренуватися руками, візьміть окремий навчальний репозиторій із парою комітів: зробіть дві теки, змініть текст тільки в другій, перевірте обидві й приберіть зайву. Жодних сервісів і акаунтів для цього не потрібно.