用 Git Worktrees 让多个 Coding Agent 并行运行

共享工作目录让多个代理必然冲突

一个 Claude Code 或 Codex 会话在仓库里运行顺畅，但同时启动登录和支付两个任务时，两个进程开始编辑相同文件，项目陷入混乱。相同的目录、相同的分支，让并行代理直接互相踩踏。

这种冲突的根源在于所有代理共享同一个工作目录和检出分支。任何一个代理修改文件、切换分支或运行 git 操作，都会立刻影响其他代理正在读取或写入的状态。登录模块的改动可能覆盖支付模块的临时变更，反之亦然。结果是文件内容错乱、git 状态不一致，甚至出现无法自动解决的合并冲突。

单个代理工作良好，是因为它独占整个仓库环境。所有上下文、文件锁、编辑历史都围绕这一个进程展开，不存在竞争。但当开发者希望同时推进两个独立特性时，传统单目录模式立刻失效。进程之间没有天然的隔离边界，任何并行尝试都会演变为对同一组文件的争夺。

中高级工程师在实际项目中经常遇到这个墙：一个代理负责重构认证流程，另一个同时优化支付回调逻辑。两者都需要修改 models/user.go 和 handlers/payment.go，冲突几乎不可避免。信号中明确描述的“同一工作目录、同一检出分支、两个进程编辑相同文件”正是这一现象的直接写照。

Git worktrees 为每个代理创建独立目录

用 Git Worktrees 让多个 Coding Agent 并行运行：Git worktrees 为每个代理创建独立目录

Git worktrees 的核心机制是为同一个仓库在文件系统上创建多个独立的工作树。每个 worktree 拥有自己的工作目录、索引和 HEAD 指针，却共享底层的 .git 对象数据库。这意味着代码对象只存一份，但每个代理可以在完全隔离的目录中检出不同分支、进行独立修改，而不会互相干扰。

这种分离直接解决了信号里提到的目录共享问题。原先所有代理挤在同一个文件夹里，现在每个代理获得专属文件夹，例如 repo-main、repo-login、repo-payments。它们可以同时打开编辑器、运行测试、执行 git commit，上下文完全隔离。

上下文隔离带来的另一个好处是分支管理更灵活。一个 worktree 可以停留在 feature/login 分支，另一个停留在 feature/payments 分支，甚至可以让某个 worktree 处于 detached HEAD 状态进行实验性改动，而不影响其他工作树的状态。

对开发者而言，这相当于把原本“一个仓库一个进程”的限制打破成“一个仓库多个独立进程”。文件系统级别的隔离保证了代理不会意外读取到其他任务的中间状态，也避免了编辑器插件、linter、构建缓存之间的交叉污染。

为每个代理新建 worktree 的具体命令流程

用 Git Worktrees 让多个 Coding Agent 并行运行：为每个代理新建 worktree 的具体命令流程

实际操作中，开发者可以在主仓库目录下快速创建多个 worktree。假设主仓库位于 ~/projects/myapp，首先确保已经在 main 分支：

1
2
3

git worktree add ../myapp-login feature/login
git worktree add ../myapp-payments feature/payments
git worktree add ../myapp-experiment -b temp/experiment

第一条命令会在上级目录创建 myapp-login 文件夹，并切换到 feature/login 分支。第二条类似。第三条新建一个分支并创建 worktree。

创建完成后，每个目录都是完整可用的仓库环境。可以分别进入对应目录启动 coding agent：

1
2

cd ../myapp-login && claude-code "重构登录模块"
cd ../myapp-payments && claude-code "优化支付回调"

中高级工程师通常会写一个小脚本自动化这个流程，例如 worktree-agent.sh，接收任务名称和分支名，自动创建 worktree、启动对应 agent 并记录映射关系。脚本还能检查已有 worktree，避免重复创建。

日常操作中，建议把 worktree 统一放在与主仓库平级的目录下，便于管理。完成任务后可以用 git worktree remove ../myapp-login 安全删除临时工作树，清理文件系统。

代理在独立 worktree 中完成任务后的合并路径

每个 worktree 完成任务后，开发者需要在主仓库执行合并。典型流程是先在对应 worktree 中提交变更，然后切换到主 worktree 执行 merge 或 rebase。

1
2
3
4

cd ../myapp-login
git add . && git commit -m "feat: 重构登录模块"
cd ../myapp-main
git merge feature/login

如果出现冲突，git 会提示具体文件。此时开发者可以在主 worktree 中解决冲突，commit 后删除不再需要的 worktree。Git 的三路合并算法在这里发挥作用，因为每个 worktree 的变更基于同一远程仓库的不同分支，冲突范围通常可控。

对于复杂变更，可以先在 worktree 内运行完整测试套件，确保变更质量，再合并回主分支。部分团队还会增加一步：把 worktree 的 commit 推送到远程特性分支，由 CI 系统验证后再合并主线。

这种合并路径保持了 git 原生工作流的一致性，同时把并行开发产生的冲突从“实时踩踏”推迟到“可控合并时刻”，显著降低了混乱程度。

并行运行把任务切换成本降到最低

当登录和支付两个任务可以同时推进时，开发者不再需要在两个任务之间反复切换上下文。以前的做法是完成一个任务、commit、切换分支、再启动下一个任务，现在两个 agent 可以并行工作，各自在独立 worktree 中迭代。

信号中描述的“一个终端跑登录，另一个终端跑支付”场景因此变得可行。开发者可以同时监控两个 agent 的输出，在一个任务卡住时立即切换注意力到另一个任务，而不用等待当前任务完全结束。

效率提升体现在多个维度：减少分支切换次数、降低上下文切换的心智负担、让 agent 的思考时间与人的思考时间重叠。原本串行的两天工作量，可能在一天内并行完成。

对中高级工程师来说，这意味着可以把更多精力放在架构决策和代码审查上，而不是机械地管理终端和分支状态。并行运行还让实验性重构的风险降低——可以在独立 worktree 中大胆尝试，失败了直接删除 worktree，不污染主线。

中高级工程师落地此方案的实际边界

这个方案对熟悉 git 命令的中高级工程师最为适用。他们需要理解 worktree 的共享对象模型、分支管理规范以及冲突解决流程。新手可能在第一次创建和清理 worktree 时感到困惑。

中文开发者团队在使用时需要注意路径编码问题，尤其当仓库路径包含中文时，建议统一使用英文路径避免 git 命令异常。大型 monorepo 项目中，worktree 数量过多会占用较多磁盘空间，虽然对象共享机制缓解了这个问题，但仍需监控磁盘使用。

目前尚未解决的限制包括：agent 自身对多仓库上下文的理解能力仍然有限，跨 worktree 的全局搜索和重构仍需人工协调；某些 IDE 对同时打开多个 worktree 支持不够友好，需要额外配置；团队协作时，其他成员可能不了解某个 worktree 对应的任务，需要额外文档记录。

尽管存在这些边界，在中大型项目中，结合 Git worktrees 的并行 coding agent 工作流已经能显著提升开发效率，值得有经验的工程师在日常实践中逐步落地。

参考来源