在《是时候了解一下 Git worktree 了》一文中，我们展示了如何在 Codex、Claude Code 等 Coding Agent 中利用 Git worktree 实现并行开发。但该篇文章只聚焦于单仓库场景，面对采用多仓库架构的 LLM Arena 网站时出现了一系列新痛点。不过，

多仓库架构下的痛点

LLM Arena 使用 versus 父仓库管理多个子仓库。通过 Git Submodule 将它们关联。仅在父仓库执行 git worktree add 并不能得到完整可用的开发环境，主要痛点如下：

• 子模块目录可能为空或未初始化：创建父仓库的 worktree 后子模块仍需手动同步、检出。
• 需求编号冲突导致方法冲突：并行开启多个 Agent 时两个 Session 往往会生成相同的需求编号，合并回父仓库会产生文件冲突。
• 跨机器并发缺乏全局互斥：Git 本地分支锁只能保证同一台机器上的互斥，无法防止不同机器上出现相同 REQ‑ID。

为父仓库创建独立 Worktree

创建工作区

cd versus
git worktree add -b req-01 ../req-01 origin/master
git worktree add -b req-02 ../req-02 origin/master

每个 worktree 拥有：

• 独立工作目录；
• 独立索引和当前分支；
• 共享父仓库的 Git 对象库；
• 可由不同 Coding Agent 并行操作。

在 Worktree 中初始化子模块

cd ../req-01
git submodule sync --recursive
git submodule update --init --recursive

Pain point：每次手动执行都很繁琐。而且让 Agent 临时推理生成这些步骤会消耗大量 token，且易受上下文漂移影响。怎么说呢，为此我们将上述流程封装进 w​t.sh 脚本。实现“一键式”创建、子模块初始化、端口分配和环境配置。

w​t.sh 脚本概览

# wt.sh - Versus 多需求并行开发管理脚本
## 设计目标
# • 每个需求一个独立 Git worktree。实现代码真正并行、互不干扰
# • 每个 worktree 分配独立端口，支持并行接口测试
# • 数据库共享 dev，不隔离；E2E 手动/顺序执行
# • 不改业务代码：端口与代理仅在本地 worktree 内修改 + assume-unchanged
# • 提交复用 scripts/commit.sh
## 用法示例
# ./scripts/wt.sh new  # 创建工作区。例如 req-001
# ./scripts/wt.sh list # 列出所有工作区 + 端口 + 状态
# ./scripts/wt.sh go  # 切换到指定工作区
# ./scripts/wt.sh remove  # 删除工作区
# ./scripts/wt.sh info  # 查看单个工作区详情
# ./scripts/wt.sh current # 查看当前目录所属的工作区

建立 Worktree‑Manager Agent

在原有 Harness “一句话交付产品功能”闭环中，我们使用了若干 Sub‑Agent 完成需求闭环。 现在需要在流程最前面加入专职的 worktree-manager Agent，以确保每个需求在创建之初就拥有独立的工作空间。怎么说呢，

Agent 定义

---
再看name。"worktree-manager"
description: |
当需要启动新的需求或修改任务时请先触发此 Agent 为其创建专属 Git Worktree。此 Agent 必须在 requirement-designer 之前执行。以确保 REQ‑ID 与分支名已预占，防止并行开发中的编号冲突与端口重复。---
说到steps，- name: Check Existing Worktrees
run这方面，|
bash scripts/wt.sh list
git worktree list
- name: Allocate REQ‑ID & Create Branch
run的观点是，|
# allocate_req_id 会返回唯一的 REQ‑ID，如 REQ-001
REQ_ID=$
git checkout -b "feat/${REQ_ID}" master
- name: Create Worktree via wt.sh
run这方面。|
bash scripts/wt.sh new "${REQ_ID}"

调整 Sub‑Agent 编排流程

将 worktree-manager 插入原有流水线前置，使得每个需求从“创建 Worktree → 分配 REQ‑ID → 开始设计”形成完整流程。

REQ‑ID 冲突及其方法

Pain point：Sesssion A 与 Session B 同时进入各自的 worktree，却因为读取同一份需求目录列表而产生相同的编号（例如两者都得到 REQ-007)。合并回父仓库时这些相同方法可能导致冲突。

Causal Analysis – 类似数据库“丢失更新”问题

A 与 B 同时读取最新编号 N → 都计算出 N+1 → 同时尝试写入 N+1 → 冲突。若不加以控制，将导致代码合并失败、人工介入成本激增。

L​ocal Git 锁作为天然互斥机制

• Create branch first:

git checkout -b "feat/REQ-007" master || {
echo "Branch already exists,reallocate ID"
# 重试分配新的 REQ-ID 并
尝试创建分支
}

If branch creation fails,Agent重新调用 alert_id,从元数据文件 L​ocal 原子性保护.

.wt 元数据登记

WT_META_DIR="${ROOT_DIR}/.wt"
write_meta {
local id=$1 branch=$2 req_id=$3
echo "WT_REQ_ID=${req_id}"> "${WT_META_DIR}/${id}.meta"
}

This registry serves two purposes:

• A quick lookup to avoid reusing already allocated IDs.
• An audit trail for debugging allocation issues.

Pain point 到跨机器场景

The above mechanism only guarantees mutual exclusion on a single machine because all agents share same local Git repository. When developers run Agents on different machines,same REQ‑ID may still be generated. For such cases we recommend:

• A centralized service that atomically hands out IDs.
• A remote atomic reference using .

自动化工作流概览

Pipelines Overview

说到使用者。"开启 5 个 Agent 协作实现 XXX 需求"
│▼ worktree-manager → 创建隔离 worktree + 分配端口 │ status=completed
│▼ requirement-designer → 输出 PRD.md + 分配 REQ-ID │ status=awaiting_review ⏸ 人工审核
│▼ go-api-implementer → 输出 Go 实现 + api-summary.md │ status=completed
│▼ frontend-engineer → 输出 React 实现 │ status=completed
│▼ test-case-designer → 输出 api-test-cases.json │ status=completed
│▼ integration-test-runner │ status=has_bugs → Bug 修复循环
│▼ e2e-test-executor │ status=all_passed → 流水线完成

Pain point：The workflow still relies on users manually remembering command syntax and order,which defeats purpose of automation.

/teamwork-preview 指令化编排

Aspired by Google Antigravity’s demo of “Agent Teams”,we introduced a stable entrypoint:

This single slash command triggers entire sub‑agent chain automatically. Under hood it wraps original rules from # CLAUDE.md into a Skill called "teamwork-preview",which handles:

• The trigger & execution order of each Sub‑Agent;
• Status persistence via external JSON/YAML state files;
• Error recovery and retry policies.

The skill abstracts away low‑level details,letting users simply issue one command while ensuring consistent environment setup。port allocation and REQ‑ID handling.

与常用方法

• Pushing inference aside from execution： Agents focus on understanding requirements and orchestrating steps;deterministic shell scripts perform concrete actions.
• Simplify concurrency control by reusing existing constraints： Leveraging Git’s branch creation failure as an atomic lock avoids building fragile custom lock services.
• Acknowledge scope limits： Local Git mutual exclusion works only on a single host;cross‑machine scenarios demand a centralized ID service or remote atomic references.
• User pain points addressed：
  • No more manual submodule init – script does it automatically.
  • No more REQ‑ID collisions – branch pre‑allocation guarantees uniqueness per machine.
  • No more memorizing complex CLI sequences – one `/teamwork-preview` call launches whole pipeline.

Coding Agents dramatically accelerate code generation and task execution。but y do not magically eliminate classic engineering challenges such as concurrency,state consistency,and resource isolation. The faster we develop and higher our parallelism,more rigorously we must enforce se foundational safeguards.

​

。

---