AI 编程真正改变的，不是我敲代码更快，而是同一时间能推进的事情突然变多了：一个 Agent 在修构建，一个在写文档，一个分支还留着线上问题的复现现场。

这时最容易出问题的不是模型能力，而是工作目录。切分支会覆盖未提交改动；为了并行而多 clone 几份，又会把依赖、构建产物和仓库状态弄得难以辨认。git worktree 正好补上了这一层：共享一个 Git 对象库，同时提供多个相互隔离的工作目录。

一句话总结

git worktree 是同一个 Git 仓库的多个 checkout。每个 checkout 有自己的分支、文件和未提交改动，但共享提交历史与对象数据库。

它在 AI 时代特别重要，是因为它把“并行执行”变成了可管理的物理边界：每个任务、每个 Agent、每个验证环境都有独立目录，而不是在同一个工作区里抢状态。

同一仓库的多个独立工作目录

它和 clone、branch 到底有什么区别

先把三个概念分开：

概念解决什么文件目录Git 对象库
branch保存不同历史线通常共用一个目录共用
clone获得一份完整副本独立各自一份
worktree同时 checkout 多个分支独立共用同一份

普通开发里，分支和工作目录是一对一的：我在 main 上改了一半，要看 hotfix，就得 stash、提交半成品，或者冒险切分支。worktree 允许我把 hotfix 放进另一间“房间”。

它不是替代 branch。branch 仍然定义历史；worktree 只是让多条历史线同时拥有可工作的文件系统。

最常用的三个命令

假设当前仓库在 ~/project：

1
2
3
4
5
6
7
8
# 为已有分支创建一个并行工作目录
git worktree add ../project-hotfix hotfix/login-timeout

# 新建分支并同时创建目录
git worktree add -b feat/agent-release ../project-agent-release main

# 查看所有 worktree 与对应分支
git worktree list

完成后再清理：

1
2
git worktree remove ../project-hotfix
git worktree prune

remove 删除的是那个工作目录，不会删除分支和提交历史。要删除分支，仍然显式执行 git branch -d。这条边界很重要：目录生命周期和代码历史生命周期不是一回事。

为什么 AI 让它从技巧变成基础设施

过去我一个人开发，切分支的成本主要是心智负担。现在一个需求经常天然拆成多条链路：实现、测试、构建、文档、代码审查、发布验证。AI Agent 能同时跑这些任务，但它不会自动解决共享目录的冲突。

例如一次发布排障，最稳妥的结构往往是：

  • 主 worktree：保留当前真实状态，不动未提交工作。
  • release/* worktree：只从指定 commit 打包发布，保证制品可追溯。
  • fix/* worktree：验证补丁或复现失败，不污染发布输入。
  • docs/* worktree：写说明、补测试或整理变更。

人和 AI Agent 在隔离工作区中协作

这不是为了形式上的“多 Agent”。真正的收益是，每个 Agent 的输入和输出都更明确：它只能在自己的目录里修改；构建日志、node_modules、生成文件和未提交 diff 都不会悄悄影响另一个任务。

一个适合 Agent 的工作流

我更推荐按任务边界创建，而不是按人名创建：

1
2
3
4
# 保持主目录只做集成和最终检查
git worktree add -b fix/importer-patch ../fiaos-fix-importer main
git worktree add -b release/1.1.4 ../fiaos-release-1.1.4 main
git worktree add -b docs/release-notes ../fiaos-release-docs main

然后约定四件事：

  1. 一个 worktree 只服务一个可描述的目标。
  2. Agent 完成后报告 commit、验证命令和残留风险，而不是只说“改好了”。
  3. 发布 worktree 必须从明确 commit 创建；不要把主目录中未提交的实验改动一起打包。
  4. 主 worktree 不承担长时间构建和大范围试验，它只负责集成、审查与最终提交。

这套约定比“让 Agent 小心一点”可靠得多。边界落在目录和 Git 记录上，后续的人也能复现。

它不解决什么

worktree 不是隔离环境的万能替代品。

  • 它们仍共享同一个仓库的 Git 对象库，不能把它当成权限隔离。
  • 端口、全局缓存、Docker 容器、数据库和远端环境依然可能冲突。
  • 同一分支不能被两个 worktree 同时 checkout；这是 Git 用来避免同一分支出现两份独立未提交状态的保护。
  • 大型依赖目录通常会各自安装，磁盘占用仍需管理。

如果任务需要真正的安全边界或不同系统镜像，仍然要用 container、VM 或独立构建机。worktree 解决的是代码工作区隔离，不是运行时隔离。

要不要用 / 我的判断框架

值得上：你同时处理发布、修复、审查或多个 Agent 任务；你不想为了切分支 stash 半成品；你需要从一个干净 commit 产出可追溯制品。

可以再等：仓库很小、任务严格串行，而且你几乎没有未提交改动。

重点关注：不要把 worktree 当成“多开几个目录”就结束了。给每个目录一个任务边界、一个分支和一份验证证据，才是它在 AI 时代真正放大交付能力的方式。