Worktree більш підходить як одноразовий каталог для виконання

Останнім часом поширеним є використання, коли спочатку готують worktree, а потім відкривають у цьому каталозі Codex / Claude Code. Оскільки ранні моделі мають обмежену контекстуальну пам’ять і запам’ятовування, якщо одразу в основному робочому просторі дозволити їм створювати worktree, легко заплутати поточний каталог і каталог, створений worktree, після стиснення контексту, що може призвести до неправильних налаштувань.
Але у такого підходу є й побічний ефект — з часом worktree починає використовуватися як довгостроковий робочий простір. Проблема в тому, що worktree за своєю природою прив’язаний до гілки, і з часом у нього з’являються додаткові труднощі з перемиканням гілок, синхронізацією та очищенням.
Багато хто також не дуже чітко розрізняє різницю між worktree і окремим клонуванням. Його перевага полягає не у «додатковому каталозі», а в тому, що він по суті залишається тим самим репозиторієм, що й основний, — вони ділять git object бібліотеку, мають низькі витрати на копіювання і не потребують повторного завантаження через мережу. Це особливо зручно для великих репозиторіїв. Тому, якщо потрібно тимчасово створити паралельний каталог для виконання, worktree дуже підходить. Лише у випадках, коли потрібно повністю ізольований об’єктний сховище, наприклад, для відображення у Docker або віртуальну машину, краще використовувати локальне клонування.
Щонайменше для Codex / Claude Code зараз ця проблема вже не така критична. Я зараз більше схиляюся до роботи безпосередньо у головному каталозі, дозволяючи їй створювати worktree за потреби, після завершення роботи об’єднувати зміни і видаляти worktree. Це краще відповідає початковому призначенню worktree: низькозатратного тимчасового каталогу для виконання, а не довгострокового другого робочого простору.
Ще один крок — я зараз експериментую з ідеєю підтримки глобального робочого простору, у якому відкриті всі проекти Codex, і він сам керує клонуванням і worktree за правилами. Це полегшує збереження пам’яті та її послідовність, і якщо потрібно одночасно працювати з кількома проектами, він знає, як по черзі їх оновлювати і тестувати разом.