Parallel Isolation: Worktrees
📚 Навигация по серии: Предыдущая статья 〔24 Правила и хуки (Hooks)〕 добавила в Codex «заслонки» и «триггеры», автоматизируя рутину. В этой статье мы перейдем в другое измерение — вместо того чтобы заставлять один Codex делать больше, мы позволим нескольким задачам выполняться одновременно, не мешая друг другу. Worktree (рабочее дерево) — это основной механизм изоляции, который Codex использует для этой цели: как его создавать, использовать, почему одну и ту же ветку нельзя извлечь в двух местах одновременно и как Handoff (передача) переносит работу между передним и задним планом. В следующей статье 〔26 Интеграция с Git и GitHub〕 мы разберем, как отправлять коммиты, пушить изменения и создавать PR после завершения работы.
Расскажу о глупости, которую я совершил в марте этого года.
В тот день, решив сэкономить время, я запустил сразу два локальных (Local) потока в Desktop App Codex для редактирования одного и того же репозитория. В одном потоке я поручил ему провести рефакторинг слоя данных, а в другом — заодно поправить роутинг. Я радовался: мол, двойной запуск — двойная эффективность. В итоге оба потока изменили один и тот же файл config.ts. Как только второй поток закоммитил изменения, он наполовину затер то, что только что записал первый. Я несколько минут тупо смотрел на разноцветные красно-зеленые блоки в git diff, пока до меня наконец не дошло: это не Codex сошел с ума, это я усадил двоих писать одной ручкой на одном листке бумаги.
После этого я послушно начал использовать то, что и следовало использовать — Worktree. Теперь, если нужно вести параллельную работу над одним проектом, я всегда создаю Worktree. Каждый поток получает изолированную копию кода, и с тех пор у меня больше ни разу не случалось этой неприятности с взаимным перезаписыванием.
В 07-й статье о Desktop App я уже кратко упоминал Worktree — это один из трех режимов (Local / Worktree / Cloud) при создании нового потока, работающий в паре с функцией Handoff для переноса задач между передним и задним планом (облачный режим Cloud мы здесь подробно разбирать не будем, он вынесен в отдельную 10 Облачные задачи статью). В этой статье мы копнем глубже: как именно устроена изоляция на низком уровне, почему существует строгое правило «ветку можно извлечь только в одном месте», как работает Handoff в обоих направлениях и как чистить накопившиеся копии. Если не разобраться в этих нюансах заранее, вы обязательно наступите на эти грабли.
Прочитав эту статью, вы получите:
- Простое объяснение в одно предложение того, какую проблему решает Worktree и чем оно принципиально отличается от «запуска двух потоков Local»
- Пошаговую инструкцию по созданию потока Worktree в Desktop App, а также разбор неочевидного момента: почему по умолчанию он находится в состоянии detached HEAD (отсоединенный HEAD)
- Главное правило, на котором чаще всего спотыкаются: одну и ту же ветку нельзя одновременно извлекать в двух местах; какую ошибку вы получите и как ее обойти
- Два сценария двунаправленного переноса потоков между Local и Worktree с помощью Handoff и случаи их применения
- Использование скрипта setup для локального окружения (Local environment), чтобы в новом Worktree сразу при создании устанавливались все зависимости
- Что делать, если накопившиеся Worktree занимают слишком много места на диске: сколько хранится по умолчанию, какие файлы не удаляются и можно ли восстановить удаленный снимок
⚠️ Worktree, Handoff и Local environments — это функции Desktop App Codex, в CLI нет соответствующих параметров вроде
--worktree(так что не ищите их в терминале). Любые упоминания кнопок, настроек по умолчанию и параметров в этой статье основаны на официальной документации Codex (Worktrees / Local environments); интерфейс и функции могут меняться от версии к версии, ориентируйтесь на то, что видите на своем экране.
01 Разберемся сначала: какую именно проблему решает Worktree
Сразу к выводу: Worktree решает проблему «когда в одном репозитории нужно делать несколько независимых задач одновременно, не боясь перезаписать код друг друга». Условие успеха здесь только одно — эти задачи не должны пытаться одновременно редактировать одни и те же файлы.
Вспомните предыдущие статьи: в основном мы работали в рамках «одного потока» — запускали задачу, давали инструкции, и ИИ шаг за шагом ее выполнял. В 90% случаев этого достаточно. Но бывают два момента, когда такой подход начинает стеснять.
Во-первых, когда задачи изначально независимы друг от друга. Например: «поправить верстку фронтенда», «исправить баг на бэкенде» и «написать тесты». Они никак не связаны, но вам приходится выстраивать их в очередь — сначала фронтенд, потом бэкенд, хотя их вполне можно делать параллельно.
Во-вторых, когда вы хотите проверить новую идею, но боитесь испортить незавершенную работу. В вашей текущей рабочей области куча нескоммиченных изменений, и вдруг вам приходит в голову проверить другую гипотезу. Если делать это на месте, можно все сломать и запутаться в собственных правках.
В такие моменты вы можете подумать: «Ну так запущу просто несколько потоков параллельно». — И здесь вас ждет ловушка. Если все потоки запущены в режиме Local и указывают на одну и ту же рабочую директорию проекта, вы совершите ту же глупость, о которой я рассказал вначале: несколько экземпляров Codex будут одновременно менять одни и те же файлы, и более поздние записи затрут более ранние.
Аналогия: медицинская карта пациента. Карта одна. Если три врача из разных отделений попытаются одновременно вписать туда свои рекомендации, их записи перепутаются или перекроют друг друга. Правильный подход — выдать каждому врачу по копии карты, чтобы они писали отдельно, а затем объединить их записи в оригинал. Именно это и делает Worktree: на основе одной истории коммитов Git создает для вас несколько независимых рабочих директорий. У каждой из них свой набор файлов, но они используют общую папку .git (метаданные, история коммитов и ветки у них общие). Изменения, вносимые в одном Worktree, никак не затронут файлы в другом.
Официальная документация формулирует это преимущество очень просто:
Каждое рабочее дерево (worktree) содержит независимую копию каждого файла вашего репозитория, но при этом они делят общие метаданные о коммитах, ветках и т. д. (папку
.git). Это позволяет вам переключаться на разные ветки и работать с ними параллельно.
Вот реальные сценарии, когда вам точно понадобится Worktree:
- «Нужно параллельно исправить баг в одном модуле и добавить фичу в другой» — запускаем по потоку Worktree на каждую задачу, файлы никак не пересекутся
- «Работа сделана наполовину, коммитить рано, но хочется срочно протестировать другую идею» — создаем Worktree, проверяем гипотезу там. Исходные файлы остаются в целости и сохранности. Если эксперимент не удался, просто удаляем это дерево
- «Нужно запустить масштабный рефакторинг с помощью Codex в фоне, пока вы продолжаете писать код» — отправляем задачу выполняться в фоновом Worktree (подробнее о фоне и переднем плане в следующем разделе)
💡 Резюме в одном предложении: Worktree позволяет одновременно выполнять независимые задачи в одном репозитории без риска взаимного перезаписывания (как выдача копии медкарты каждому врачу). Главное правило — задачи не должны пытаться писать в одни и те же файлы, иначе параллельная работа превратится в хаос.
На схеме выше: один репозиторий Git порождает три независимых worktree, в каждом из которых выполняется своя задача Codex без взаимного влияния.
02 Создание потока Worktree в Desktop App
Теперь, когда мы понимаем, зачем это нужно, давайте разберем, как его создать. Весь процесс состоит из нескольких кликов в Desktop App, никаких команд вводить не нужно.
Worktree работает только внутри репозитория Git — ведь под капотом используются стандартные возможности
git worktree. Выбранный вами проект обязательно должен быть Git-репозиторием, иначе этой опции просто не будет.
Создание за четыре шага
Шаг 1: Выберите режим Worktree при создании нового потока. В нижней части окна ввода нового потока переключите режим с Local на Worktree. (Здесь же можно выбрать локальное окружение для запуска скрипта setup, подробнее об этом в разделе 05).
Шаг 2: Выберите исходную ветку. Под полем ввода вам предложат указать, на основе какой ветки создать это рабочее дерево — это может быть main / master, любая ветка функции или даже ваша текущая рабочая ветка вместе со всеми незакоммиченными локальными изменениями. Это очень удобно: вы можете перенести свои текущие наработки прямо в новое дерево.
Шаг 3: Отправьте инструкции. После этого Codex создаст рабочее дерево git worktree на основе выбранной ветки и начнет работу.
Шаг 4: Решите, что делать дальше. По окончании работы у вас есть два пути — либо остаться в этом Worktree и продолжить (делать коммиты, пушить, открывать PR), либо перенести поток обратно in Local с помощью функции Handoff (раздел 04).
Неочевидный, но важный факт: по умолчанию Worktree находится в состоянии detached HEAD
Этот момент чаще всего вызывает недоумение у новичков, поэтому разберем его отдельно.
Создаваемый Codex Worktree по умолчанию не привязан ни к одной ветке, он находится в состоянии detached HEAD (отсоединенный HEAD). Это значит, что он указывает напрямую на конкретный коммит, а не на имя ветки. Из официальной документации:
По умолчанию Codex работает в состоянии «отсоединенного HEAD» (detached HEAD).
Зачем это сделано? Документация объясняет это очень практично: так Codex может создавать несколько Worktree одновременно, не засоряя список ваших веток. При выполнении git branch вы не увидите кучу временных веток только потому, что запустили пять параллельных задач.
А если вы хотите превратить эти изменения в полноценную ветку? В верхней части панели потока есть кнопка Create branch here (Создать ветку здесь). Нажмите ее, и текущее рабочее дерево переключится на новую ветку, после чего вы сможете коммитить, пушить и отправлять PR.
💡 Резюме в одном предложении: Создание потока Worktree состоит из четырех шагов: выбор режима Worktree → выбор исходной ветки → отправка команды → решение о сохранении. Помните, что по умолчанию создается состояние detached HEAD. Чтобы сделать коммит и запушить ветку, сначала нажмите Create branch here.
03 Важнейшее железное правило: одну ветку нельзя извлекать в двух местах одновременно
Этот раздел короткий, но он важнее всех остальных. На этом спотыкались многие разработчики, включая меня.
Сформулируем правило жестко. У Git есть непреложное ограничение: одна ветка в один момент времени может быть извлечена (checkout) только в одном рабочем дереве. Если вы переключились на ветку feature/a в каком-то Worktree, то в вашем основном локальном репозитории (Local) вы не можете одновременно переключиться на ту же feature/a. Это же правило действует и в обратную сторону.
Аналогия: книга в библиотеке. Уникальный бумажный экземпляр книги может взять только один читатель. Если его забрал читатель А, читатель Б не сможет получить его в то же самое время. Дело не в жадности библиотеки, а в том, что статус книги «у кого она сейчас на руках» может иметь только один однозначный ответ. То же самое и с ветками Git: имя ветки (refs/heads/<name>) представляет собой единственный ответ на вопрос «каково текущее состояние этой ветки». Если бы ветку можно было извлекать параллельно в двух местах и коммитить туда одновременно, это привело бы к хаосу — потере коммитов или конфликтам индексов. Поэтому Git решает этот вопрос радикально: одна ветка — только одно рабочее дерево в данный момент времени.
Что произойдет, если нарушить это правило? Допустим, Codex завершил задачу в Worktree, и вы нажали Create branch here, назвав ветку feature/a. Теперь вы хотите открыть эту ветку в своем основном локальном проекте, чтобы посмотреть код. Git незамедлительно выдаст ошибку:
fatal: 'feature/a' is already used by worktree at '<WORKTREE_PATH>'Это означает: данная ветка уже занята указанным рабочим договором, и извлечь ее локально невозможно.
Что делать? Правильное решение — использовать Handoff, а не пытаться решить проблему силой. Официальная документация предлагает два пути:
- Если нужно просто быстро взглянуть: переключитесь на другую ветку внутри самого Worktree, тем самым освободив
feature/a. - Если вы хотите продолжить работу над этой веткой на локальном компьютере: передайте поток в Local с помощью Handoff (подробнее в следующем разделе), не пытайтесь держать ветку открытой в двух местах сразу.
💡 Резюме в одном предложении: Одна ветка может быть активна только в одном рабочем дереве одновременно (как одна книга выдается в одни руки). Попытка извлечь её в двух местах вызовет ошибку
already used by worktree. Чтобы перенести изменения локально, используйте Handoff, не пытайтесь переключать ветки вручную.
04 Handoff: двусторонний перенос потоков между Local и Worktree
В предыдущем разделе мы постоянно упоминали Handoff. Давайте разберем эту функцию досконально. Это официальное решение от авторов Codex для обхода ограничения на одновременное извлечение ветки, а также базовое действие, которое вы будете совершать каждый день при работе с Worktree.
Для начала сформируем мысленную модель: Local — это передний план (фронт), а Worktree — задний план (бекграунд). Local (основной локальный каталог) — это ваша основная рабочая область, где вы пишете код сами, держите открытой привычную IDE и запускаете сервер разработки. Worktree — это изолированная копия проекта, которая тихо меняется в фоне. Handoff переносит задачу (поток) между передним и задним планом.
Аналогия: кухня ресторана с открытой стойкой и заготовочным цехом. Открытая стойка (Local) — это место на виду у гостей, где шеф-повар оформляет и отдает готовые блюда. Заготовочный цех (Worktree) — это помещение в глубине, где шинкуют овощи и варят бульоны. Где готовить блюдо — зависит от этапа: если нужно быстро доделать детали перед подачей или проверить вкус, его выносят к стойке; если нужно освободить место для других блюд, пока это медленно тушится в кастрюле, его уносят в цех. Handoff как раз и отвечает за эти перемещения, при этом Codex берет на себя все низкоуровневые операции Git, избавляя вас от необходимости писать команды git worktree вручную.
Официальная документация прямо объясняет причину существования Handoff (как раз в продолжение предыдущей темы):
Это важно, потому что Git разрешает извлекать одну ветку только в одном месте одновременно.
Handoff работает в двух направлениях, решая две основные задачи:
Направление 1: Worktree → Local (перенос фонового потока на передний план). Нажмите кнопку Hand off в заголовке потока и выберите Local. Когда это нужно? Когда вы хотите проверить изменения в своей привычной среде разработки — просмотреть diff в любимой IDE, запустить локальный сервер разработки или если ваше приложение может быть запущено только в одном экземпляре и не позволяет запустить еще один в Worktree. Это мой любимый сценарий: я даю Codex задачу написать фичу в фоновом Worktree, а после завершения делаю Handoff в Local и спокойно просматриваю изменения строка за строкой в своем редакторе.
Направление 2: Local → Worktree (отправка потока с переднего плана в фон). Работает и в обратную сторону. Если вы начали задачу в Local, но хотите освободить основное рабочее пространство для других дел, сделайте Hand off этой ветки в Worktree. Codex продолжит выполнение задачи в фоновом режиме, а вы сможете переключиться на другие локальные дела.
Есть очень удобная, но незаметная деталь: каждый поток жестко привязан к конкретному рабочему дереву (worktree). Если вы перенесли его через Handoff в Local, а через какое-то время решили вернуть обратно в фон, Codex отправит его именно в то же самое рабочее дерево, чтобы вы продолжили ровно с того места, где остановились, не создавая всё заново.
И последний важный нюанс, который нужно твердо запомнить:
Поскольку Handoff опирается на операции Git, любые файлы, перечисленные в вашем
.gitignore, не будут переноситься вместе с потоком.
Это означает, что файлы вроде .env или локальные кэши, которые не отслеживаются в Git, не переносятся при Handoff. Это напрямую связано с тем, что Worktree по умолчанию создается абсолютно чистым. О том, как решить эту проблему, мы поговорим в следующем разделе.
| Worktree → Local | Local → Worktree | |
|---|---|---|
| Направление | Из фона на передний план | С переднего плана в фон |
| Типичный сценарий | Проверка изменений в привычной IDE, запуск серверов, которые не могут дублироваться | Освобождение основного пространства; фоновое выполнение долгой задачи |
| Кто управляет Git | Автоматически Codex | Автоматически Codex |
Файлы из .gitignore | Не переносятся | Не переносятся |
💡 Резюме в одном предложении: Handoff переносит потоки между Local (передним планом) и Worktree (фоном) в обоих направлениях (как шеф-повар перемещает блюда между стойкой и заготовочным цехом). Все операции Git выполняются автоматически и безопасно, но файлы из
.gitignoreпри этом не переносятся.
05 Подготовка нового Worktree: скрипт setup для локального окружения (Local environment)
В продолжение темы из предыдущего раздела: поскольку Worktree — это абсолютно чистая копия, расположенная в другой директории, в ней изначально отсутствуют любые неуправляемые в Git файлы, зависимости или конфигурации. Типичная проблема: запускается новый Worktree, а там нет папки node_modules или файла .env, и работа ИИ тут же останавливается с ошибкой.
В апреле я сам попался на этом: радостно запустил Worktree, чтобы Codex поправил бэкенд, а он не смог подключиться к базе данных. Я долго не мог понять почему, пока до меня не дошло: файла .env просто нет в директории Worktree (как мы выяснили, файлы из .gitignore не переносятся). После добавления скрипта setup таких вопросов больше не возникало.
Аналогия: чек-лист для открытия нового филиала. Главный офис (ваш Local) полностью укомплектован оборудованием и товарами, а в новом филиале (Worktree) пока только голые стены. Умная компания использует стандартный чек-лист открытия: завезти мебель, установить технику, разложить товар. Скрипт setup для локального окружения и есть такой чек-лист: каждый раз, когда Codex создает новое рабочее дерево для потока, этот скрипт запускается автоматически, устанавливая зависимости и выполняя сборку.
Как и где это настраивается? Документация объясняет:
- Вы настраиваете локальное окружение через панель настроек (Settings) в приложении Codex, а результирующий конфигурационный файл сохраняется в каталоге
.codexв корне вашего проекта. - Этот конфигурационный файл можно добавить в Git для совместного использования с командой — достаточно настроить его один раз, и у всех разработчиков рабочие деревья будут создаваться сразу готовыми к работе.
Вот пример скрипта setup для проекта на TypeScript из документации:
npm install
npm run buildПри создании нового Worktree эти две строки выполнятся автоматически: установятся пакеты npm, соберется проект, и Codex сможет сразу приступить к работе без лишних задержек.
Различия между ОС: Если шаги инициализации различаются в зависимости от ОС (macOS / Windows / Linux), вы можете прописать отдельные скрипты setup для каждой платформы. В Windows особенности работы Desktop App регламентируются официальной документацией для Windows.
Попутно упомянем еще одну возможность: помимо скриптов setup, локальное окружение позволяет настраивать действия (Actions). Вы можете вынести частые команды вроде «запустить dev-сервер» или «прогнать тесты» в виде быстрых кнопок в верхней панели приложения, чтобы выполнять их в один клик во встроенном терминале. Мы кратко касались этого в 07-й статье, здесь углубляться не будем.
💡 Резюме в одном предложении: Worktree — это чистая копия репозитория без папки зависимостей и файлов вроде
.env. Используйте скрипт setup для локального окружения (хранится в папке.codexи может быть закомичен), чтобы автоматически развертывать окружение при создании нового дерева, аналогично открытию нового филиала по чек-листу.
06 Что делать, если Worktree скопилось слишком много: очистка, лимиты и восстановление снимков
Параллельная работа — это здорово, но со временем возникает практическая проблема: рабочие деревья занимают место на диске. Каждое содержит полную копию файлов проекта, свои зависимости и кэш сборки. Если открыть десяток потоков, свободное место на диске начнет стремительно таять. Поэтому Codex помогает контролировать количество рабочих деревьев в разумных пределах.
Начнем с двух фактов о том, где физически находятся эти папки:
- Codex создает и администрирует рабочие деревья централизованно в каталоге
$CODEX_HOME/worktrees(по умолчаниюCODEX_HOMEуказывает на~/.codex, мы говорили об этом в 18-й статье про конфигурацию). - По умолчанию Codex хранит до 15 последних рабочих деревьев, управляемых приложением. Вы можете изменить этот лимит в настройках или полностью отключить автоудаление, чтобы контролировать диск самостоятельно.
Как Codex выбирает, какие рабочие деревья удалять? Он старается сохранять важные. Согласно документации:
Управляемое Codex рабочее дерево НЕ будет автоматически удалено, если:
- К нему привязан закрепленный (pinned) диалог
- Связанный с ним поток все еще выполняется
- Оно помечено как постоянное (permanent worktree, см. ниже)
Рабочее дерево будет удалено автоматически, если:
- Вы отправили связанный поток в архив (archive)
- Codex необходимо удалить старые рабочие деревья, чтобы уложиться в заданный лимит
И самое приятное — перед удалением всегда создается резервная копия (снимок):
Перед удалением рабочего дерева, управляемого Codex, приложение сохраняет снимок проделанной в нем работы. Если после удаления вы откроете этот диалог снова, вам будет предложено восстановить его.
Это значит, что даже если рабочее дерево было очищено, сам поток сохраняется в вашей истории. Вы можете открыть его и нажать кнопку восстановления — наработки не пропадут.
Напоследок разберем разницу между двумя понятиями, чтобы избежать путаницы: управляемые Codex рабочие деревья и постоянные рабочие деревья (permanent).
| Управляемое Codex (по умолчанию) | Постоянное (permanent) | |
|---|---|---|
| Как создается | Автоматически при создании потока в режиме Worktree | Вручную через меню проекта в боковой панели |
| Привязка к потокам | Обычно используется только в одном потоке | Может служить основой для запуска нескольких потоков |
| Автоматическое удаление | Да (при превышении лимита или архивации) | Нет, никогда не удаляется автоматически |
| Лучше всего для | Временных, одноразовых задач | Долговременного, стабильного окружения |
Проще говоря: для быстрой проверки идей используйте режим по умолчанию — система сама приберет за вами; если же вам нужна постоянная изолированная среда, к которой вы будете регулярно возвращаться, создайте постоянное рабочее дерево через меню проекта. Оно будет оформлено как отдельный проект и никогда не удалится автоматически.
💡 Резюме в одном предложении: Рабочие деревья создаются в
$CODEX_HOME/worktrees. По умолчанию хранятся 15 последних, а старые или заархивированные удаляются автоматически (с возможностью восстановления из снимка). Закрепленные, активные или постоянные деревья не удаляются. Используйте стандартный режим для временных задач и постоянные деревья для долгосрочной работы.
07 Практика: проходим базовый жизненный цикл Worktree в Desktop App
Теория без практики мертва. Ниже описан сценарий, который вы можете полностью проделать в интерфейсе Desktop App Codex, используя любой Git-репозиторий. Для каждого шага указан ожидаемый результат. Пройдите этот путь один раз, чтобы закрепить навык на уровне мышечной памяти.
Подготовьте любой Git-репозиторий (если готового нет, просто создайте пустую папку и выполните
git init). Напоминаем, что это функция исключительно Desktop App, в CLI ее нет.
Шаг 1: Создайте новый поток и переключитесь в режим Worktree
Нажмите кнопку создания нового потока в приложении. Под полем ввода переключите режим с Local на Worktree и выберите исходную ветку (для теста подойдет main).
Ожидаемый результат: Режим переключится на Worktree, появится выбор исходной ветки. Появление этих элементов означает, что вы создаете изолированную копию, не затрагивая оригинал.
Шаг 2: Дайте простую безопасную задачу
Отправьте простую команду, которая не меняет код, например: «Составь список заголовков всех файлов Markdown в этом проекте».
Ожидаемый результат: Codex создаст рабочее дерево на основе выбранной ветки и начнет выполнять задачу. Рабочая директория этого потока теперь находится в $CODEX_HOME/worktrees (по умолчанию ~/.codex/worktrees), что полностью отделено от вашего локального проекта (Local).
Шаг 3: Убедитесь в изоляции через встроенный терминал
Откройте встроенный терминал потока (в macOS по умолчанию это сочетание клавиш Cmd + J, на Windows — согласно настройкам вашей системы) и выполните команду:
git worktree listОжидаемый результат: В списке рабочих деревьев, помимо вашего основного каталога, появится дополнительная строка, указывающая на путь в .../.codex/worktrees/.... Это подтверждает, что вы действительно находитесь внутри изолированной копии.
Шаг 4: Попробуйте сделать Handoff в Local
Нажмите кнопку Hand off в верхней панели потока и выберите перенос в Local.
Ожидаемый результат: Поток переместится в вашу основную рабочую область. Теперь изменения видны в вашей привычной IDE и консоли. Codex выполнил все необходимые Git-команды под капотом, вам не пришлось делать это вручную.
Шаг 5: Очистка
Чтобы не засорять диск временными рабочими деревьями после тестов, проще всего отправить этот поток в архив (archive). Как мы выяснили в разделе 06, после архивации связанное дерево автоматически удаляется (с созданием снимка на случай восстановления). Вы также можете заглянуть в настройки, чтобы скорректировать лимиты.
Ожидаемый результат: Поток исчезнет из списка активных задач, а его рабочее дерево будет удалено, освобождая дисковое пространство. Успешное удаление файлов означает, что вы полностью прошли весь цикл.
Пройдя эти пять шагов, вы закрепили на практике основной процесс: «создание копии → проверка изоляции → Handoff на передний план → очистка». При реальной работе всё будет строиться точно так же, только задачи станут сложнее и потоков будет больше.
💡 Резюме в одном предложении: Весь процесс состоит из пяти шагов: создаем поток Worktree → запускаем тест → выполняем
git worktree listдля проверки → переносим в Local через Hand off для проверки → архивируем поток для автоочистки. Один практический запуск дает больше понимания, чем чтение десятка инструкций.
08 Итоги
В этой статье мы подробно разобрали тему параллельной работы нескольких задач Codex в одном репозитории: от причин необходимости изоляции до очистки диска от неиспользуемых копий.
Давайте сведем ключевые моменты в единую таблицу:
| Что вы хотите сделать | Что использовать | Ключевые моменты |
|---|---|---|
| Понять причины изоляции | Два условия использования Worktree | Параллельная работа в одном репозитории без редактирования одних и те же файлов (как копия карты для каждого врача) |
| Создать изолированный поток | Режим Worktree для нового потока | Выбор исходной ветки; по умолчанию detached HEAD, для коммитов сначала нажмите Create branch here |
| Избежать конфликтов веток | Строгое правило Git | Одна ветка может быть активна только в одном рабочем дереве, при нарушении возникнет ошибка already used by worktree |
| Переносить задачи | Handoff (передача) | Перенос потоков между Local (передний план) и Worktree (фон); операции Git выполняются автоматически, файлы из .gitignore не переносятся |
| Подготовить окружение | Скрипт setup для локального окружения | Конфигурация в папке .codex, можно коммитить; зависимости устанавливаются автоматически при создании Worktree |
| Контролировать место на диске | Правила очистки + постоянные деревья | По умолчанию хранятся 15 деревьев, перед удалением создается снимок; для долгой работы создавайте постоянные деревья |
Теперь вы умеете:
- Объяснять назначение Worktree и помнить правило «не редактировать параллельно одни и те же файлы»
- Создавать потоки Worktree в Desktop App, понимая специфику состояния detached HEAD и используя Create branch here для создания веток
- Следовать правилу «одна ветка — одно активное дерево» и использовать Handoff вместо попыток переключиться на занятую ветку вручную
- Переносить потоки между Local и Worktree с помощью Handoff в обе стороны, а также настраивать скрипты setup для автоматической подготовки окружения
- Контролировать очистку рабочих деревьев и понимать, в каких случаях они защищены от автоудаления
Вспоминая ту нелепую ситуацию из начала статьи с одновременным запуском двух потоков Local, главной ошибкой было отсутствие изоляции — я заставил два процесса Codex делить один инструмент. Теперь у вас есть ключ к изоляции в виде Worktree и инструмент переноса в виде Handoff. Вы вооружены знаниями, которые уберегут вас от досадных ошибок.
В следующей статье 〔26 Интеграция с Git и GitHub〕 мы продолжим тему контроля версий. В этой главе вы уже столкнулись со многими операциями Git: преобразованием Worktree в ветку, неявными действиями Git при Handoff, а также подготовкой к коммитам и отправке кода. Большинство из них пока выполнялись силами самого Codex. В следующей части мы подробно рассмотрим возможности интеграции Codex с Git и GitHub: от создания коммитов, пушей и PR прямо в приложении до работы с интерактивным просмотром изменений (diff) и синхронизацией с GitHub. Помните: Worktree надежно изолирует изменения, но в какой-то момент их нужно аккуратно влить обратно в основную ветку — и именно этому посвящена следующая статья.