09｜Git worktree：让多个 Agent 并行写代码但互不污染

本篇是《从头重新学 AI 编程》系列第 9 篇。

上一篇我们把前七篇的能力串成了一套完整工作流，从需求到提交整条链路怎么走。

上半场到这里就结束了。这一篇开始进下半场，聊一些能让那套工作流再往上走一截的玩法。

先说第一个，Git worktree。

我先讲一个我自己经常碰到的场景，你大概率也遇到过。

你让 AI 帮你优化待办列表的渲染性能，它给了你一个方案，你觉得还行。但它又补了一句，其实还有另一种写法，可能更好。

这时候你心里就痒了，想两个都试试，对比一下到底哪个快。

然后问题就来了。

你在同一个目录里，先让 AI 试方案 A，再让它试方案 B。结果方案 B 的代码把方案 A 给覆盖了。你想对比，连对比的东西都没了。

更崩溃的是另一种情况。你嫌一个一个试太慢，干脆开两个会话，让两个 AI 在同一个目录里各写各的。它俩直接打起来了。一个刚写完的文件，另一个上去就给改了，或者删了。最后你看着一堆乱七八糟的改动，根本分不清是谁干的。

我第一次遇到这事的时候是真的有点懵，我寻思我明明开了两个会话，怎么还会串。后来才反应过来，会话是两个，但它俩操作的是同一个文件夹啊。

Git worktree 就是来解决这个的。

它一句话就能讲明白，同一个仓库，开多个目录，共用一份 git 历史。

你平时打开的那个项目目录，本身就是一个 worktree。Git 允许你从同一个仓库再拉出来几个额外的目录，每个目录有自己的分支、自己的文件状态，但底下的提交历史是同一份。

我给你画一下大概长什么样。

my-repo/ 主工作目录，你自己平时用的 ├── .git/ 唯一的一份 git 历史 └── src/ ../wt/virtual-list/ worktree 1，放方案 A └── src/ （checkout 在 feature/virtual-list 分支） ../wt/pagination/ worktree 2，放方案 B └── src/ （checkout 在 feature/pagination 分支）

两个目录里的文件是完全独立的。你在 worktree 1 里改了什么，worktree 2 里一点感觉都没有。但它俩共享同一份 git 历史，所以最后你可以把表现最好的那个分支，干干净净地合回主分支。

你可能会问，那我为什么不直接 git branch 切来切去就行了？

因为切分支是在同一个目录里换文件。你切到 A 分支，目录里就是 A 的代码，切到 B，目录里就变成 B 的了。同一时间你只能看到一个。而 worktree 是把它们摊在不同的文件夹里，三个方案同时摆在你面前，你可以并排看、并排跑、并排测。

这块需要注意一下，如果你只用一个 AI、一个会话，老老实实串行干活，那 worktree 你确实用不太上。

但当你开始想玩多 Agent 并行的时候，它就几乎是刚需了。

你想想第 7 篇讲的 Subagent，主 Agent 做实现，Review Agent 看 diff，Test Agent 补测试。如果这几个 Agent 全挤在同一个目录里操作，会发生什么？

两个 Agent 同时 git add，可能就丢改动了。一个 Agent 偷偷切了个分支，另一个 Agent 不知道，稀里糊涂也在那个分支上写了起来。dev server 都想抢 3000 端口。node_modules 和 lockfile 被两边同时改。

一团乱麻。

worktree 把这些问题一次性摁住了。每个 Agent 一个独立目录，独立 HEAD，独立工作区，谁也碰不到谁。

我给你看个具体的例子，还是我们这个待办应用。

假设列表数据越来越多，渲染肉眼可见地卡了，你想优化。常见的方案有三种，虚拟列表、分页、懒加载。你拿不准哪个最适合你这个场景，那就别纠结了，三个都试。

先给三个方案各开一个 worktree。

git worktree add ../todo-virtual-list -b feature/virtual-list git worktree add ../todo-pagination -b feature/pagination git worktree add ../todo-lazy-load -b feature/lazy-load

三条命令跑完，你手里就有了三个独立的目录。每个目录里都是一整套完整的项目代码，但各自待在不同的分支上。

然后你开三个会话，分别让三个 AI 钻进各自的目录里干活。

# 会话 1 cd ../todo-virtual-list # 让 Agent 在这儿实现虚拟列表 # 会话 2 cd ../todo-pagination # 让 Agent 在这儿实现分页 # 会话 3 cd ../todo-lazy-load # 让 Agent 在这儿实现懒加载

三个 Agent 并行开工，互相看不见对方。等都做完了，你把三个方案拉出来对比，跑个性能测试，看哪个数据最好，就把哪个合回主分支。剩下两个分支删掉就行。

这种感觉其实挺爽的，相当于你一个人同时带了三个工人，让他们用三种思路盖同一面墙，最后你挑一面最结实的留下。放一年前你想都不敢想。

常用的命令也就那么几条。

# 看看现在都开了哪些 worktree git worktree list # 用完了清理掉 git worktree remove ../todo-virtual-list git branch -D feature/virtual-list

记得用完一定要清。不然时间一长，你磁盘上会躺着一堆早就忘了的废弃 worktree，占着地方还碍眼。

这里有个坑我提醒一下，新手很容易栽。

worktree 新拉出来的目录，是不会自动带上 .gitignore 里那些被忽略的文件的。

也就是说，node_modules/ 和 .env 在新目录里压根不存在。

你得在新目录里重新装一遍依赖。

cd ../todo-virtual-list npm install

如果你项目还依赖环境变量文件，比如 .env，那也得手动拷过去，或者干脆写一个 bootstrap 脚本，每次新建 worktree 自动把这些事办了。我自己就是写了个小脚本，省得每次手动来一遍，老忘。

回到第 5 篇那块再说一句。

第 5 篇讲上下文管理的时候我说过，缓解上下文膨胀的一个办法是开新会话。但开新会话只是把对话历史清空了，你人还在同一个目录里。

worktree 是再往前走一步，连文件系统都给你隔离开了。

这两个东西是可以叠在一起用的。在一个独立的 worktree 里让 Agent 放手去干，万一搞砸了，回滚也好、删掉重来也好，你的主工作区一根毛都不会少。这种安全感，跟我们前面一直在聊的「有基线可退」其实是一回事，只不过 worktree 把这个基线从「一次提交」升级成了「一整个独立的工作目录」。

给你一个小练习。

下次你遇到一个「我也拿不准哪种写法更好」的功能，别再在一个目录里改来改去覆盖来覆盖去了。开两个 worktree，让 AI 在两个目录里分别实现两种思路，最后并排比一比。你体会一下那种「两个方案都在手边、随便挑」的从容感，跟以前那种试一个删一个、心里没底的状态，完全是两回事。

下一篇我们聊一个把重复劳动固化下来的东西，Skill，怎么把你反复对 AI 说的那几句话，变成一个可以一键复用的工作流。

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～