一个反常的走红
先说一件反常的事：一个 2015 年就发布的 Git 功能——git worktree（Git 2.5 引入）——冷了整整十年，大多数开发者从没用过它。然后在 2026 年，它突然成了 GitHub Copilot 应用的默认工作模式，Claude Code 给它做了专门的命令行参数，AI 编程圈几乎人人都在聊它。
一个十年没人理的老功能，凭什么突然翻红？
这个问题值得认真回答。因为它背后藏着一个比"教你用一个 Git 命令"值钱得多的判断——工具的命运，往往不取决于它有多好，而取决于它的使用者什么时候出现。
上一篇我们说：你以为的 Agent 新框架，其实是 40 年前的老配方。这一篇正好是它的镜像：一个老工具，等来了它的新场景。
worktree 是什么：一个大脑，多个身体
先把这个功能用人话讲清楚。
正常情况下，一个 Git 仓库只有一个工作目录：你在这个目录里写代码，某一时刻只能站在一个分支上。想临时切去修个 bug？那就得先 stash 把手头的活儿藏起来 → 切分支 → 修完 → 切回来 → stash pop 恢复现场。编辑器上下文丢了，装好的依赖可能要重来，心理负担还重。
git worktree 换了个思路：让一个仓库同时挂载多个工作目录，每个目录站在不同的分支上，但它们共享底层同一份 .git 数据库（历史、对象、分支信息）。一句话类比：一个大脑，多个身体——每个身体各干各的活，记忆是同一份。
有人会说：我多 clone 几份仓库不也一样？不一样。四个维度的差距：
| 维度 | 多 clone 几份 | worktree |
|---|---|---|
| 存储 | 每份都是完整仓库（500MB 的仓库 ×2 = 1GB） | 一份 .git + 每个目录只放工作文件 |
| 信息同步 | 各 clone 互为孤岛，这边 fetch 的那边不知道 | 单一数据库，一处 fetch 全部可见 |
| 配置 | 每份都要重新设 hooks / config | 全部共享 |
| 安全阀 | 没有——可能两处同时改同一分支 | 有——同一分支禁止同时挂到两个目录 |
功能是好功能。那为什么冷了十年？
为什么等了十年：人是单线程的
答案简单到有点扎心：因为人是单线程的。
一个开发者，同一时刻只能在一个分支上专注写代码。"同时需要五个并行的工作目录"这件事，对单线程的人类来说是个伪需求——偶尔切个分支，stash 忍一忍也就过去了。工具再精巧，没有需求就没有存在感。
改变这一切的是 AI。GitHub 官方博客在 2026 年 6 月把话说得很直白：
"AI 让我们前所未有地并行工作……有了 worktree，agent 和人类可以并行做更多事。它已是 GitHub Copilot 应用的默认模式，也是许多现代工具的默认模式。"
想想现在的 AI 编程是什么形态：你同时开三五个 agent 会话——一个修 bug、一个写新功能、一个跑重构。每个 agent 都在真实地读写文件。如果它们挤在同一个工作目录里，就会互相踩踏：你刚让 A 改到一半，B 把文件格式化了一遍，C 又基于错误的中间状态跑起了测试。
一个人变成了 N 个并行会话，"每个会话一个物理隔离的工作目录"瞬间从伪需求变成刚需。worktree 十年前就把答案准备好了，只是在等提问的人到场。
实战：Claude Code 里怎么用，以及三个坑
光讲道理不够，说说具体怎么用（以下来自多个一线实测，来源：git-worktree）。
基本工作流：Claude Code 提供了 --worktree 参数，启动时自动创建一个隔离的 worktree（带一个随机名字），agent 在里面干活，退出时问你保留还是删除。Anthropic 官方还支持给 subagent 各开一个 worktree：官方案例是 10 个并行 agent 同时做一次大型代码迁移，每个 agent 在自己的树里改代码、跑测试、按模块拆 PR 汇回主干。
四种并行姿势： 1. 多任务并行：N 个 worktree + N 个会话，修 bug 和写功能互不干扰，不用干等 2. 同一任务双实现：让两个会话各写一版方案，跑测试对比，留优汰劣——不弄脏主环境的 A/B 测试 3. 角色分工：前端 / 后端 / 测试 agent 各占一棵树，避免同目录冲突和上下文污染 4. 自动化：写个自定义命令，开新功能时自动建树建分支
三个真实的坑： 1. push-to-main 陷阱：agent 在 worktree 里干完活，如果不显式推送到自己的分支，默认可能直接推到 main——main 没设分支保护的话就是事故现场。务必配分支保护 2. 未推送就删树 = 白干：worktree 删除时，没推送的改动和提交历史一起消失 3. 依赖膨胀：每棵树要独立装依赖（node_modules 们），并行五棵树就是五份磁盘和五次安装
还有一条经验值得记住：个人并行上限建议 2-3 个会话——树可以无限开，人脑收敛冲突的带宽是有限的。
隔离是个光谱：从 worktree 到 micro VM
把镜头拉远一点，你会发现 worktree 只是"agent 隔离"这个大问题的最轻量解。
上一篇我们拆过 Palantir 的 Agent 基础设施：它把每个 agent 跑在内核级隔离的 micro VM 里，配持久化账本，崩了能恢复、挂起零成本。
这两者其实是同一根光谱的两端：
- 轻端——worktree：只隔离工作目录，共享机器和运行环境。成本约等于零，适合个人开发者、可信 agent、以小时计的任务
- 重端——micro VM：连内核都隔离，防恶意代码，配 durable execution。成本高，适合企业级、高风险、以天计的长任务
选型思路也就清楚了：按你能承受的事故等级选隔离强度。 个人写代码，agent 手滑了大不了删树重来，worktree 足够；医院里的出院 agent 手滑了是真实世界的事故，那就得上重隔离。
收尾：老工具等来了它的用户
回到开头那个判断。
git worktree 这十年里没有变得更好，它几乎没变。变的是世界：AI 让"一个人的并行度"从 1 变成了 N，于是一个为并行而生的老工具，一夜之间站到了舞台中央。
这和上一篇《你以为的 AI Agent 新框架，其实是 40 年前的老配方》是一对镜像判断：
- 新框架的地基，是老配方——事件溯源、CQRS、Actor 没变，被 Agent 重新打包
- 老工具的翻红，靠新场景——worktree 没变，被 Agent 重新需要
合在一起，是同一个更大的判断：AI 时代的技术变革，新的往往不是"发明"，而是"匹配"——旧答案和新问题的重新匹配。 谁能更快识别出"这个新需求，旧世界里早有答案"，谁就能少造轮子、少走弯路。
所以下次再看到什么"为 AI 而生的全新工具"，不妨先问一句：它是真的新，还是一个老朋友换了身衣服，终于等到了自己的时代？
最后照例交代"来路"：这篇的所有事实，来自我知识库里 git worktree 主题的 7 个独立来源——Git 官方文档、GitHub 官方博客、三位一线开发者的实测视频与两篇深度实践——交叉验证后写成。「飞说 AGI」的老规矩：不做热点的转述，只做有来路的判断。 💬 上一篇的问题继续有效：你还见过哪些「老工具等来新场景」或「新概念其实是老配方」？评论区聊聊——点赞最高的，下一篇就拆它。
评论