Dev Workflow · Git
用 git worktree 做并行开发（也适用于 AI 协作）
2026-01-17 21:11 · 工程师 / AI 辅助开发 · git worktree 基础 + 多 Agent 协作流程
把每个任务/Agent 隔离到独立工作区与分支，让并行变更可审、可回滚、可合并。
要点速览
- worktree 让同一仓库挂多个工作目录：你可以同时 checkout 多个分支，不用频繁 stash 或重复 clone。
- AI 协作落地的关键不是“更快写代码”，而是“隔离变更 + diff 审阅 + 可控合并”的流程。
- 推荐映射：一个任务（或一个 AI Agent）= 一个分支 + 一个 worktree + 一次可评审的提交/PR。
关键洞见
- worktree 解决的是“并行 checkout”，不解决“并行改同一文件”的冲突；冲突依然要 merge/rebase。
- 把 AI 当作“提交候选生成器”：它在自己的 worktree 里产出可复现的变更，你只需要审阅与合并。
- 稳定协作来自约定：命名、验收命令（tests/lint）、合并策略、清理策略缺一不可。
步骤指南（新手友好）
新手模式
- 先懂边界：worktree 做什么
读一遍git help worktree：它管理同一仓库的多个 working tree；每个 worktree 都是独立目录/独立 HEAD（但共享对象库）。 - 为任务开目录：add 一个 worktree
示例：mkdir -p .worktrees后运行git worktree add -b ai/alice/fix-foo .worktrees/ai-alice-fix-foo origin/main。 - 让 AI 只在自己的 worktree 改
在新终端把 AI 工具的工作目录指到.worktrees/ai-alice-fix-foo；要求它“先跑测试→改→再跑测试→给出 diff/commit”。 - 用 diff 评审：再决定合并
在主工作区审阅：git diff main..ai/alice/fix-foo或直接开 PR；通过后再 merge/squash。 - 合并后清理：remove + prune
完成后：git worktree remove .worktrees/ai-alice-fix-foo；必要时git worktree prune清理残留元数据。
检查清单
-
每个 worktree 绑定独立分支（不要在多个 worktree 同时 checkout 同一分支）。
-
worktree 目录统一放在
.worktrees/（并写入.gitignore）。 -
给每个 Agent 写清“验收命令”（例如
npm test/pytest/cargo test）。 -
合并策略先定：
merge/squash/rebase选一种并遵守。 -
定期维护：
git worktree list+ 清理废弃 worktree/分支。
奥卡姆优先（只保留必要的）
- 先从“1 个 Agent + 1 个 worktree”开始跑通闭环。
- 并行前先拆任务：尽量让不同 Agent 改不同模块/文件集合。
- 把约束写进任务单（边界/禁止改动/必须通过的命令），减少来回对话成本。
SVG 图解
专家视角
Git core team（git-worktree 手册） — 官方文档视角：定义、约束与推荐用法
- 立场： worktree 的价值是：在同一个仓库上挂多个 working tree，用最低成本并行处理多个分支/任务。
- 论据： 手册强调：同一仓库可同时 checkout 多个分支；也可以创建 detached 的临时 worktree 做实验；完成后用
git worktree remove清理。 - 边界： 它隔离的是目录与 checkout，不隔离语义冲突：并行修改同一文件仍需 merge/rebase；生命周期要管理（remove/prune/lock）。
“A git repository can support multiple working trees, allowing you to check out more than one branch at a time.” — git-worktree(1) — DESCRIPTION
方案对比
| 方案 | 适用场景 | 收益 | 代价 | 关键风险 | 第一步 |
|---|---|---|---|---|---|
| A | 个人/小团队：本地并行多个任务/Agent | 零 clone、切换快、目录隔离强；适合把 AI 输出当作“候选提交”。 | 依赖纪律：命名、清理、合并规则必须一致，否则很快混乱。 | 误删未提交 worktree；或把变更做在错误目录导致审阅困难。 | 约定 .worktrees/ 目录 + 分支前缀 ai/<agent>/。 |
| B | 团队/CI：Agent 在容器/远端并行跑 | 环境一致、可审计；可并发跑测试/静态检查，并自动产出 PR。 | 搭建与权限成本高；流程复杂后容易被绕过。 | PR 堆积、噪声变多；或因为脚本不严谨导致合并事故。 | 写脚本：创建分支→准备 worktree/环境→跑 Agent→推送→开 PR。 |
证据与置信度
| 主张 | 证据 | 置信度 | 来源 |
|---|---|---|---|
| 同一仓库支持多个 worktree，可同时 checkout 多分支 | 官方手册 DESCRIPTION 段落的定义与示例（见来源）。 | 高 | git-worktree(1) manual |
下一步
- 把你正在做的工作拆成 2 个互不冲突的小任务，分别创建两个 worktree。
- 为每个 worktree 写一份“AI 任务单”（目标/边界/验收命令/不允许修改的文件）。
- 把 create/remove/prune 封装成脚本或 Makefile target，做到一键开工/收工。
细节（可选）
二级页面
保持主报告简洁。复杂推导、长表格、深度材料放到二级 HTML 页面，再在这里以链接方式引用。
来源
收尾总结
把 worktree 当作“并行工作目录”，把 AI 当作“提交候选生成器”。
- 用分支+worktree 隔离并行变更：可审、可回滚、可控合并。
- AI 协作的关键是流程：任务拆分→验收命令→diff/PR 评审→合并。
- 从小规模开始，形成命名/清理/合并的团队约定，再逐步上 CI/自动 PR。
一个下一步动作
现在就选一个小任务：创建 `ai/
“用一句收束全篇的核心引言。
可换行以形成节奏。”
— Name