AI Coding Agent 下的 git worktree 模式

这个专题解决什么问题

当你开始用 AI coding agent 真正写代码时，问题往往不再是“会不会切分支”，而是：

• 一个 agent 正在改功能，另一个任务突然要求修 hotfix
• 你想让 agent 评审另一个分支，但不想污染当前工作区
• 你需要并行跑实验改动、回归验证、文档整理
• 你希望每个任务都有自己独立目录、独立上下文、独立恢复路径

这时只靠 stash + switch 往往越来越脆弱。git worktree 更适合作为 AI coding agent 的默认并行模式，因为它让“同一仓库、多个任务上下文”天然分开。

为什么 worktree 特别适合 AI agent

AI agent 和人类开发者的差异之一，是它会更频繁地：

• 同时推进多个子任务
• 在不同目标之间快速切换
• 写完代码后立即进入验证、回滚、比较、补丁整理

如果所有任务都挤在一个工作目录里，会很快出现这些问题：

• 当前未提交改动阻塞分支切换
• agent 不得不反复 stash / pop
• 回头复盘时，很难说清哪个改动属于哪个任务
• 一旦误操作，恢复边界不清楚

而 worktree 模式的优势是：

1. 每个任务一个目录，天然隔离上下文
2. 同一对象库共享历史，不需要重复 clone 全仓
3. 可以把“实现”“验证”“评审”“热修”拆成平行工作区
4. 任务结束后直接清理 worktree，不必把临时现场堆在 stash 里

最适合的几个场景

1. 一个主任务 + 一个紧急修复

主 worktree 继续让 agent 写功能，另一个 worktree 专门给 hotfix。

2. 一个实现 worktree + 一个验证 worktree

让 agent 在主目录改代码，同时在第二个 worktree 里跑回归、对比 main、复现 bug。

3. 一个功能 worktree + 一个 PR 整理 worktree

当你需要整理提交、压缩历史、补文档时，不必在当前开发目录里来回改上下文。

4. 多 agent 并行

不同 agent 分别绑定不同 worktree，比共享一个目录稳定得多。这样每个 agent 的文件改动、分支状态和实验结果都更可控。

一个推荐的最小模式

主目录：主任务

git status
git branch -vv

新开目录：给 AI agent 的并行任务

git worktree add ../repo-review review/fix-copy

或者：

git worktree add ../repo-hotfix hotfix/login-timeout

此时你就可以明确指定：

• 主目录给“实现 agent”
• ../repo-review 给“验证 / review agent”
• ../repo-hotfix 给“紧急修复 agent”

在 AI agent 协作里最重要的规则

规则 1：一个 worktree 只服务一个清晰任务

不要让一个 agent 在同一个 worktree 里同时做功能开发、热修和提交流程整理。

规则 2：把 worktree 名字写成任务语义

比如：

git worktree add ../repo-agent-rebase-lab lab/rebase-cleanup
git worktree add ../repo-agent-hotfix hotfix/login-timeout
git worktree add ../repo-agent-review review/cart-empty-state

目录名和分支名都应带任务语义，后面复盘才不会混。

规则 3：高风险历史操作优先放到独立 worktree

像这些动作：

• rebase
• reset
• cherry-pick
• range-diff
• 发布前整理提交

都更适合放到独立 worktree 里做。这样即使做错了，也不会把当前主工作区一起带乱。

规则 4：验证和实现分开

如果 agent 一边改代码、一边就在同目录切回去验证，很容易把验证环境也搅乱。分成两个 worktree 通常更稳。

和 stash 模式相比，worktree 模式好在哪里

stash 更适合：

• 短时间暂停
• 很快要回来继续
• 只是临时把现场放一放

worktree 更适合：

• 并行任务持续几十分钟到几小时
• 需要多个稳定上下文
• 需要把实现、验证、评审、修复拆开
• 希望 AI agent 的任务边界非常清晰

一句话说，stash 更像“短暂停车位”，worktree 更像“多个正式工位”。

多 agent 下的推荐操作顺序

1. 先定义任务边界
2. 再决定每个任务是否单独给一个 worktree
3. 给每个 worktree 配清晰的目录名和分支名
4. 明确哪个 worktree 负责实现，哪个负责验证
5. 任务完成后及时 remove，不要长期堆积

一个典型团队用法

假设你让 3 个 agent 并行：

• Agent A：继续开发 feature/copilot-sidebar
• Agent B：验证 main 上最近一个 UI 回归
• Agent C：处理线上 hotfix

更稳的做法是：

git worktree add ../repo-agent-a feature/copilot-sidebar
git worktree add ../repo-agent-b review/ui-regression
git worktree add ../repo-agent-c hotfix/header-overlap

这样每个 agent 都在自己目录里工作。你回头看 git status、看 diff、做 commit、关任务，都会更清楚。

常见误区

误区 1：AI agent 反正快，混在一个目录里也没关系

恰恰相反。agent 越快，越需要上下文边界明确，否则一次误切换就会把多个任务状态混在一起。

误区 2：worktree 只是高级技巧，不适合日常

对于多任务、AI 辅助、高频切换的团队，worktree 反而应该成为日常默认选项之一。

误区 3：worktree 只是为了避免 stash

不止。更大的价值是让任务、目录、分支和恢复路径都变得显式。

什么时候不一定要用

• 当前工作区本来就很干净
• 只是做一个 2 分钟的小切换
• 你确认不会需要并行上下文

这时普通 git switch 依然足够。

一组很适合 agent 协作的命令

git worktree list
git worktree add ../repo-agent-review review/fix-copy
git worktree add ../repo-agent-hotfix hotfix/login-timeout
git worktree remove ../repo-agent-review

练习建议

git status
# 确认当前仓库正常
# 假设你已经有 feature、review、hotfix 三类任务

继续学习建议

推荐继续阅读：

1. git worktree
2. parallel work with worktree
3. prepare commits before pull request
4. hotfix and urgent fixes