WHAT - git worktree 开发的并发模型

文章目录

• [一、为什么以前没人用 worktree](#一、为什么以前没人用 worktree)
• [二、AI 时代发生了什么变化](#二、AI 时代发生了什么变化)
• [三、问题：多个 agent 会"互相踩代码"](#三、问题：多个 agent 会“互相踩代码”)
• [四、git worktree 是什么](#四、git worktree 是什么)
• • 核心能力
  • 例子
  • 类比一下更好理解：
• [五、node_modules 爆炸](#五、node_modules 爆炸)
• [六、pnpm 的 global virtual store](#六、pnpm 的 global virtual store)
• • 实际结构
  • 类比
  • 结果
• [七、pnpm 官方自己也这么做](#七、pnpm 官方自己也这么做)
• 八、总结
• • 开发范式变了
  • 并行开发的本质要求
  • [最优解 = 两个工具组合](#最优解 = 两个工具组合)

AI 编程代理改变了"开发的并发模型"，从"人类单线程开发"变成"多代理并行开发"，从而让一些过去冷门的工具（git worktree）变成刚需。

一、为什么以前没人用 worktree

核心原因：人是单线程的。

传统开发模式是：

• 一个开发者
• 同一时间只做一个任务
• 分支切来切去（checkout）

比如：

git checkout feat/a
# 做完
git checkout main
git checkout fix/b

即使你有多个分支，也是串行使用

所以：

"同时开 5 个分支？谁会这么干？"

确实没人这么干，因为：

• 人脑只能 focus 一个上下文
• 多开只会混乱
• IDE、node_modules、环境都不好管理

所以 worktree 在这个时代没有需求

二、AI 时代发生了什么变化

关键变化：我们不再是唯一的"开发执行体"

现在可以：

• 同时开 5~10 个 AI agent（Claude Code / Codex）

• 每个 agent 做一个任务：

  • A：写 feature
  • B：修 bug
  • C：写测试
  • D：重构

本质上变成了：

调度者（manager） + 多个并行执行 worker

三、问题：多个 agent 会"互相踩代码"

如果我们让多个 agent 在同一个目录工作：

• 会同时改同一批文件
• 会互相覆盖
• git 状态混乱
• 甚至 node_modules 冲突

这时候就需要：

真正的隔离环境（像 Kubernetes Pod 一样）

四、git worktree 是什么

核心能力

一个仓库，多份"工作目录"

传统 git：

repo/
  .git/
  src/

worktree 后：

repo/           (bare 仓库，不直接开发)
  .git/

main/           ← worktree 1
feat-a/         ← worktree 2
fix-b/          ← worktree 3

每个目录：

• 对应一个分支
• 可以同时存在
• 可以同时运行

但关键点：

git 对象（代码历史）只有一份，不会复制仓库

例子

git clone --bare repo

创建一个"中央仓库"（不工作）

然后：

git worktree add ./feat-a feat/task-a

给 Agent A 一套：

• 独立目录
• 独立分支
• 完整代码

类比一下更好理解：

概念	类比
bare repo	数据库
worktree	每个 agent 的"容器"
branch	每个任务

五、node_modules 爆炸

即使 worktree 解决了代码隔离，还有个大坑：

Node 项目依赖很大

假设：

• node_modules = 500MB
• 10 个 worktree = 5GB

六、pnpm 的 global virtual store

关键机制：内容寻址存储 + 符号链接

开启：

enableGlobalVirtualStore: true

开启之后：

实际结构

磁盘：
  ~/.pnpm-store/   ← 真正的依赖（只有一份）

worktree A：
  node_modules → symlink

worktree B：
  node_modules → symlink

本质：

• 所有依赖只下载一次
• 各个 worktree 只是"引用"

类比

技术	类比
npm	每个项目复制一份
pnpm	所有项目共享硬盘里的同一份

---

结果

• 第一次 install：慢

• 后面：

  • 新 worktree
  • pnpm install 几乎瞬间完成

"10 个代理，磁盘开销接近于 1 个"

七、pnpm 官方自己也这么做

因为 pnpm 自己就是：

• 大型 monorepo
• 多分支开发频繁
• CI / PR 并行多

所以他们进一步封装：

pnpm worktree:new feat/my-feature
pnpm worktree:new 10834

自动：

• 创建分支
• 创建目录
• 拉 PR
• 处理命名

八、总结

开发范式变了

从：

单人串行开发

变成：

多 agent 并行开发

并行开发的本质要求

不是"多开终端"，而是：

隔离性（Isolation）

每个 agent 必须有：

• 独立文件系统（worktree）
• 独立分支（branch）
• 独立依赖视图（pnpm symlink）

最优解 = 两个工具组合

问题	解决方案
多目录	git worktree
依赖共享	pnpm virtual store

组合起来刚好满足：

• 隔离 ✅
• 不浪费空间 ✅
• 启动快 ✅