Для 1С-разработчика, который ведёт две-три задачи с агентами: как развести их через git worktree и отдельную файловую базу в подкаталоге ib, и что делать с ConfigDumpInfo.xml.
- Каждой задаче отдельный каталог и ветка: git worktree add ..\agent1 -b agent/task-1; одну ветку в двух каталогах открыть нельзя.
- Файлы вне git, например env.json, в новом каталоге отсутствуют; для Claude Code их копирует .worktreeinclude.
- База лежит в подкаталоге ib и добавлена в .gitignore; параллельная инициализация двух баз заняла 26,2 с против 23,8 с одиночной.
- Ошибка в модуле agent1 дала syntax-check с кодом 1, у agent2 код 0: каждая ветка проверяется своей базой.
- После загрузки платформа переписывает ConfigDumpInfo.xml; вы можете добавить его в .gitignore или откатывать командой git checkout перед коммитом.
Свой worktree на ветку и своя файловая база в подкаталоге ib дают каждому агенту независимую среду проверки.
Для кого: программисты 1С, которые работают с Claude Code, Cursor или другим агентом и хотят вести две-три задачи параллельно.
Один каталог с исходниками конфигурации на двоих агентов даёт две проблемы. Агенты правят одни и те же файлы и затирают правки друг друга. И у них одна файловая база: один агент загружает в неё свою версию конфигурации, второй проверяет код и получает результат по чужим изменениям. Обе проблемы решаются одним приёмом: у каждой задачи свой рабочий каталог на своей ветке и своя база.
🌿 Рабочий каталог на ветку: git worktree
git worktree создаёт дополнительный рабочий каталог на том же репозитории. История и удалённый репозиторий общие, файлы и ветка у каждого каталога свои.
git worktree add ..\agent1 -b agent/task-1 git worktree add ..\agent2 -b agent/task-2 git worktree list
Вывод на нашем стенде:
C:/work/wt/repo 3d6861f [main] C:/work/wt/agent1 3d6861f [agent/task-1] C:/work/wt/agent2 3d6861f [agent/task-2]
Первое правило, о которое стоит споткнуться заранее: одну ветку нельзя открыть в двух каталогах. Попытка взять main, пока он открыт в основном каталоге, заканчивается отказом:
fatal: 'main' is already used by worktree at 'C:/work/wt/repo'
Второе правило: новый каталог содержит только то, что лежит в git. Файл, который не отслеживается (например, env.json с доступами к базам, как в статье про env.json), в новом каталоге отсутствует. На стенде Test-Path agent1\env.json вернул False. Если агенту нужны такие файлы, их приходится копировать после создания каталога.
У Claude Code для этого есть готовый механизм. Команда claude --worktree <имя> создаёт каталог .claude/worktrees/<имя>/ на новой ветке worktree-<имя>, а файл .worktreeinclude в корне проекта перечисляет (в синтаксисе .gitignore) файлы вне git, которые нужно копировать в каждый новый каталог: .env, env.json и подобные. Это описано в документации Claude Code; на нашем стенде команда claude --worktree не запускалась.
💽 Своя база на каждый каталог
Каждой ветке нужна база с её собственной версией конфигурации. Простое правило: база лежит внутри рабочего каталога, в подкаталоге ib, и добавлена в .gitignore.
ib/ build/ env.json
Инициализация базы из исходников своего каталога выполняется командой vanessa-runner (подробно про 3.0 - в отдельной статье цикла):
vrunner infobase init --src src --ibconnection "/F<каталог>\ib"
Две инициализации запущены одновременно в agent1 и agent2 (задачи PowerShell), обе завершились с кодом 0 за 26,2 с. Одиночная инициализация на том же стенде занимала 23,8 с, то есть параллельный запуск почти не замедляет: каждая база независима.
Изоляция проверена так. В модуле agent1 записана синтаксическая ошибка (Возврат А + ;), после чего в обоих каталогах выполнены infobase update и validate syntax-check:
--- agent1: syntax-check, код 1 --- agent2: syntax-check, код 0
Ошибка одного агента не видна другому, каждая ветка проверяется своей базой.
🪤 Грабля: ConfigDumpInfo.xml меняется после загрузки
После infobase init и infobase update в git status появилась строка M src/ConfigDumpInfo.xml, причём в обоих каталогах, включая тот, где в модулях ничего не правилось. Платформа пересчитывает в этом файле значения configVersion (хеши версий объектов), и у каждой базы они получаются свои. Изменение в agent2 выглядело так: четыре строки <Metadata ... configVersion="..."> с другими значениями.
Последствие для параллельной работы: если оба агента коммитят этот файл, при слиянии веток вы получите конфликт в файле, который не несёт смысла для ревью. Есть два выхода. Первый: добавить src/ConfigDumpInfo.xml в .gitignore, если он не нужен для вашего процесса. Второй: перед коммитом возвращать файл к состоянию ветки командой git checkout -- src/ConfigDumpInfo.xml. Файл используется при инкрементальной выгрузке конфигурации в файлы, поэтому решение зависит от того, выгружаете ли вы конфигурацию в git инкрементально. Замер, что произойдёт при инкрементальной выгрузке без этого файла, мы не делали.
🤖 Сессии агентов: tmux и возобновление
Долгая сессия агента на удалённой машине или в WSL теряется вместе с терминалом. tmux держит её живой на сервере:
tmux new -s agent1
Отключиться и оставить сессию работать: Ctrl+B, затем D. Вернуться:
tmux attach -t agent1
Для каждой задачи удобно заводить свою сессию tmux с именем ветки. На нашем стенде (Windows) tmux не установлен, команды приведены по документации tmux и не запускались.
Сам Claude Code хранит диалоги локально. claude --continue возобновляет последний диалог в текущем каталоге, claude --resume открывает список диалогов. Если сессия закончилась внутри worktree, Claude Code при возобновлении возвращает её в этот каталог (документация Claude Code, раздел про worktrees).
Замер автора: Windows 11, git, vanessa-runner 3.0.2, платформа 8.3.27.2130 (x86), файловые базы, конфигурация из одного общего модуля, одна серия.
📜 Пакетный запуск без диалога
Для разовых задач без участия человека Claude Code запускается в неинтерактивном режиме, ключ -p. Пример из документации: результат другой команды подаётся на стандартный ввод.
git log --oneline -20 | claude -p "summarize these recent commits"
Такой режим подходит для скриптов и CI. Обратите внимание: в неинтерактивном режиме Claude Code не удаляет созданные worktree при выходе, убирать их приходится командой git worktree remove. На нашем стенде claude -p не запускался.
🧹 Уборка
Когда задача закончена и ветка слита, каталог удаляется:
git worktree remove ..\agent2
На нашем стенде эта команда отказала, потому что в каталоге были изменения (та самая ConfigDumpInfo.xml):
fatal: 'C:\...\wt\agent2' contains modified or untracked files, use --force to delete it
Флаг --force удаляет каталог вместе с изменениями, поэтому сначала стоит проверить git status. Каталог базы ib в .gitignore удалению не мешает: команда отказала только из-за изменённого файла. Ветку agent/task-2 после слияния убирают отдельно, командой git branch -d.
🚧 Что не проверено
tmux, Docker,claude --worktree,.worktreeinclude,claude -p: описаны по документации, на нашем стенде не запускались.- Клиент-серверные базы. Проверялись только файловые: для серверных нужно создавать отдельную базу в кластере на каждый каталог.
- Linux и macOS. Стенд: Windows 11, платформа 8.3.27.2130 (x86), git и vanessa-runner 3.0.2.
- Крупные конфигурации. Исходники в проверке состояли из одного общего модуля, поэтому время создания базы не показывает скорость на большой конфигурации.
📚 Источники и чем эта статья отличается
Близкие темы на Infostart уже разбирали:
- «Сверим часы: 6 базовых лайфхаков для работы с ИИ-агентами»: подборка приёмов работы с агентами, от выбора модели до плана работы.
- «Опенсорс на 1С без боли: Git worktrees, XML вместо EDT и сборка расширения в одну кнопку»: worktree для выпуска одного расширения под несколько конфигураций.
- «Как дать ИИ-агенту доступ к боевой базе 1С и не поседеть»: обёртка, которая не даёт агенту записать в рабочую базу.
Здесь worktree разводит параллельных агентов: у каждого своя ветка и своя файловая база. Время инициализации двух баз замерено на стенде, грабля с ConfigDumpInfo.xml найдена там же.
📦 Файл к статье
К публикации приложен архив 07.2-companion.zip, он в блоке «Файлы» вверху страницы:
worktree_demo.ps1- сценарий из статьи: репозиторий с исходниками вsrc, два рабочих каталога на веткахagent/task-1иagent/task-2, у каждого своя файловая база (vrunner infobase init), синтаксический контроль, уборка.protokol-progona.txt- вывод сценария на стенде автора (пути заменены наC:\work\wt).komandy.md- команды git, vrunner, tmux иclaude -pиз статьи.README.md: что внутри, как пользоваться и что проверено.
🏁 Итог
Два агента на одном репозитории работают без помех, если у каждого свой worktree на своей ветке и своя файловая база в ib. Параллельная инициализация двух баз заняла 26,2 с против 23,8 с одиночной. Файл ConfigDumpInfo.xml после загрузки меняется в каждом каталоге, поэтому его лучше вывести из git или откатывать перед коммитом. Расскажите в комментариях, как вы разводите параллельные задачи агентов: отдельные базы, отдельные стенды или очередь.
Вступайте в нашу телеграмм-группу Инфостарт