Параллельное изменение кода в DeepSeek Harness в 2026: Git worktree или отдельный клон?

В обсуждении Git worktree часто смешивают три разные задачи.

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

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

Безопасностная изоляция касается ключей API, SSH-доступа, файлов конфигурации, клиентских данных и прав пользователя. Worktree не отделяет одного пользователя от другого и не гарантирует, что процесс из одной рабочей области не прочитает секреты из домашнего каталога.

Для DeepSeek Harness это особенно важно: официальный репозиторий на момент подготовки материала указывает, что проект находится в режиме developer preview и может получать обратно несовместимые изменения. Документация также показывает обычный сценарий запуска из checkout через git clone, установку зависимостей, сборку и запуск Web UI; автоматическое создание, привязка и удаление worktree в официальном описании не заявлены. Официальный репозиторий DeepSeek Harness и его инструкции запуска

Для независимого разработчика обычно подходит схема «один сеанс — одна рабочая область — одна ветка».

Например, задача на рефакторинг получает ветку agent/refactor-auth и путь /path/to/worktrees/refactor-auth, а задача на тестовое исправление — agent/fix-tests и /path/to/worktrees/fix-tests. Названия здесь приведены как шаблоны; в автоматизации лучше добавлять идентификатор задания и дату создания, чтобы путь нельзя было случайно переиспользовать.

Создание рабочей области выполняется из основного checkout:

git worktree add -b <branch-name> <worktree-path> <base-branch>

После этого сеанс DeepSeek Harness должен быть явно запущен из <worktree-path>, а не из родительского каталога. В контракте задания необходимо сохранить:

• идентификатор сеанса;
• путь рабочей области;
• имя ветки;
• исходный commit или базовую ветку;
• владельца задачи;
• разрешённые команды;
• каталог сборки и временный каталог;
• правила завершения и удаления.

Такой контракт нужен даже тогда, когда задачи выполняются одним человеком. Иначе второй сеанс может получить правильную ветку, но неправильный каталог, а оператор заметит ошибку только после появления смешанного diff.

Можно ли нескольким сеансам DeepSeek Harness использовать один репозиторий? Да, если каждый сеанс работает в собственном worktree и собственной ветке, а общие ресурсы вынесены из рабочей директории. Один и тот же каталог проекта для нескольких задач использовать нельзя: изоляция веток в этом случае не сработает, потому что checkout и незакоммиченные изменения физически принадлежат одному рабочему дереву.

Что всё равно остаётся общим

По умолчанию конфигурация репозитория Git общая для всех worktree. В официальной документации отдельно отмечена возможность включить extensions.worktreeConfig, чтобы часть параметров хранить в config.worktree; при этом не все настройки следует без проверки переносить в индивидуальную область. Раздел о worktree-specific configuration

До запуска параллельных задач нужно проверить четыре класса скрытых пересечений:

1. Репозиторные настройки. Общие hooks, remote-настройки, правила sparse checkout и некоторые параметры Git могут влиять на несколько рабочих деревьев одновременно.
2. Внешние каталоги. build, dist, DerivedData, каталоги генерации кода и временные файлы часто задаются абсолютным путём в конфигурации проекта.
3. Фоновые процессы. Сервер разработки, watcher, эмулятор, локальная база или контейнер могут продолжать работать после завершения Agent-задачи.
4. Общие секреты. Файлы в домашнем каталоге, переменные окружения, SSH-агент и менеджер ключей не становятся отдельными только потому, что каталог проекта другой.

Важно: Git worktree изолирует состояние исходного кода, но не является sandbox. Если процесс DeepSeek Harness должен быть ограничен по правам, сетевому доступу или секретам, требуется отдельный пользователь или отдельная среда.

В команде каталог нельзя считать достаточной единицей контроля. Для каждой задачи следует заранее указать, кто отвечает за изменение, кто проверяет результат и в какую ветку разрешено отправлять commit.

Подход зависит от типа работы:

• Изменение кода. Нужны эксклюзивная ветка, отдельный worktree и обязательный review перед объединением.
• Только анализ. Можно использовать detached worktree, если Agent не должен создавать commit и менять файлы.
• Исправление тестов. Рабочая область должна быть отдельной, поскольку тестовый Agent может менять fixtures, snapshots и конфигурацию проверки.
• Сборка и диагностика. Исходный код может быть изолирован worktree, но каталоги артефактов, порты и логи должны иметь собственные пути.
• Подготовка миграции или массовый рефакторинг. Если задача затрагивает общие схемы, генераторы или большое число файлов, параллельный запуск следует сначала проверить на небольшой копии.

Как параллельно изменять код и не получить конфликт веток? Разделяйте задачи по файлам и ответственности, создавайте ветви от одного зафиксированного базового commit и не позволяйте двум Agent одновременно владеть одним набором файлов. Если оба сеанса часто меняют один файл, конфликт переносится из файловой системы в merge и становится неизбежным организационным риском.

Признаки, при которых параллельность лучше остановить:

• задачи постоянно меняют одни и те же файлы;
• одна задача зависит от ещё не опубликованного commit другой;
• тесты должны выполняться только после объединения двух веток;
• генератор кода перезаписывает результаты соседней задачи;
• один Agent меняет контракт API, а другой одновременно пишет потребителей этого API.

В таких случаях безопаснее выполнить сначала структурное изменение, затем тестовое исправление, а после этого — независимый анализ. Worktree по-прежнему может использоваться для временных областей, но сами задачи должны идти последовательно.

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

Общий read-only кэш допустим, когда одновременно выполнены все условия:

• кэш не изменяется на месте;
• содержимое адресуется по версии или контрольной сумме;
• процесс сборки не удаляет и не переписывает файлы, созданные другим заданием;
• права чтения не открывают секреты соседнего проекта;
• при повреждении кэша задача может повторить загрузку.

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

Для каждого задания желательно задавать отдельные переменные:

export BUILD_DIR=/path/to/task-build/<task-id>
export TMPDIR=/path/to/task-tmp/<task-id>
export LOG_DIR=/path/to/task-logs/<task-id>

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

Официальный репозиторий DeepSeek Harness показывает, что запуск из исходников включает установку зависимостей и отдельную сборку через pnpm; следовательно, при нескольких checkout нужно заранее определить, какие каталоги установки и сборки будут общими, а какие должны принадлежать конкретной задаче. Инструкция запуска DeepSeek Harness из checkout

Безопасно ли нескольким рабочим областям пользоваться одним кэшем зависимостей? Только если кэш предназначен для совместного чтения и его жизненным циклом не управляет одна из параллельных сборок. Для изменяемых зависимостей, локальных патчей, generated-файлов и инструментов, которые выполняют очистку, нужен отдельный каталог на задачу.

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

Отдельный клон предпочтительнее, если:

• разные задачи должны использовать несовместимые версии зависимостей;
• одна сборка может удалять или переписывать кэш;
• у проектов разные .git/config, hooks или правила доступа;
• команда хочет полностью независимо архивировать и удалять рабочую область;
• длительная задача должна переживать перезапуск другого checkout;
• в репозитории используются submodule и их поведение ещё не проверено в конкретной схеме.

Официальное руководство Git указывает, что git clone создаёт новый локальный репозиторий, а также описывает варианты локального клонирования и использования reference repository. Это позволяет отделить административную структуру клона, не обязательно каждый раз загружая все объекты из сети. Актуальный синтаксис git clone и варианты локального клонирования

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

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

Нужен отдельный аккаунт macOS или отдельный удалённый Mac, когда:

• одному заданию разрешён доступ к клиентскому репозиторию, а другому — нет;
• проекты принадлежат разным организациям;
• используются разные SSH-ключи, API-токены или сертификаты;
• требуется независимый аудит действий и отзыв доступа;
• в проекте есть персональные данные, коммерческая тайна или production-подобные credentials;
• один Agent может запускать произвольные команды, а другой должен работать в ограниченном профиле.

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

Подходит ли Git worktree для долгой AI-разработки? Для долгой задачи он подходит только при наличии владельца, срока жизни, отдельного каталога артефактов и регулярной проверки состояния. Если задача должна оставаться открытой неделями, переживать смену команды и иметь независимые зависимости, отдельный клон обычно проще сопровождать. Если требуется ещё и изоляция ключей или пользователей, рабочая область должна быть перенесена на отдельный Mac.

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

Создание. Сервис выбирает базовую ветку, проверяет отсутствие занятого пути, выполняет git worktree add и записывает полученный путь в реестр задания.

Привязка. Сеанс DeepSeek Harness запускается только с рабочим каталогом из реестра. Нельзя позволять интерфейсу или оператору молча переключаться на родительский checkout.

Проверка. Перед завершением сохраняются имя ветки, commit, статус файлов, список процессов, пути к артефактам и причина остановки. Для машинной обработки подходит стабильный формат:

git worktree list --porcelain -z

Git рекомендует porcelain-формат для скриптов; он содержит отдельные записи рабочих деревьев и предназначен для разбора без зависимости от пользовательского оформления вывода. Документация Git по машинно-читаемому списку worktree

Удаление. Сначала остановите процессы и сохраните необходимые логи, затем проверьте состояние:

git -C <worktree-path> status --short
git worktree remove <worktree-path>

Git по умолчанию отказывается удалять рабочее дерево с изменёнными или неотслеживаемыми файлами; принудительное удаление через --force должно быть исключением с зарегистрированной причиной. Если каталог удалили вручную, административная запись может остаться в репозитории; для проверки используется git worktree list, а для очистки устаревших записей — git worktree prune. Правила remove, prune и repair в официальном руководстве Git

Если удаление не удалось, рабочую область нельзя немедленно считать свободной. Нужно:

• пометить задачу как требующую ручного вмешательства;
• сохранить git status, список процессов и последние логи;
• заблокировать повторное назначение того же пути;
• выяснить, есть ли незакоммиченные результаты;
• только после решения владельца применить принудительное удаление.

Автоматический скрипт, который просто удаляет каталог, создаёт две проблемы: оставляет метаданные Git и может уничтожить единственную копию незакоммиченного результата.

Перед тем как выдавать рабочую область нескольким Agent, команда может выполнить такой приёмочный прогон:

• [ ] Созданы две ветки от одного базового commit.
• [ ] Каждая задача запускается из собственного пути и не видит незакоммиченные изменения соседней задачи.
• [ ] Две задачи одновременно меняют разные файлы, после чего обе ветки корректно проходят проверку статуса.
• [ ] Тесты используют разные каталоги временных файлов и артефактов.
• [ ] Локальные серверы получают разные порты или запускаются последовательно.
• [ ] Один сеанс отменён в середине операции, после чего процессы действительно остановлены.
• [ ] Рабочая область с незакоммиченными файлами не удаляется без подтверждения.
• [ ] После штатного удаления git worktree list --porcelain не показывает устаревшую запись.
• [ ] При ручном удалении каталога проверяется необходимость git worktree prune.
• [ ] Для клиентского проекта проверено, что ключи и домашние каталоги не общие с соседней задачей.

Если этот прогон не пройден, проблема находится не в выборе команды Git, а в отсутствии изоляции процессов, кэшей или полномочий.

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

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

Отдельный аккаунт macOS или отдельный Mac выбирайте, когда различаются права доступа, заказчики, ключи или уровень доверия. Worktree и клон в таком случае являются только организацией исходного кода, а не средством защиты данных.

Главный критерий — не экономия диска и не скорость создания каталога, а граница ответственности. Если две задачи могут безопасно разделять Git-объекты и read-only кэш, используйте worktree. Если они должны разделять меньше ресурсов, переходите к отдельным клонам. Если они не должны доверять одному пользователю или одному набору секретов, разделяйте среду.

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

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