近期研究 Cursor 2.0 的多 Agent 模式时发现，其底层使用了 Git Worktree 来实现并行任务。初次接触时感到有些困惑，虽然平时常用 Git，但对 Worktree 指令了解不多。
查阅后发现，Worktree 允许在同一个 Git 仓库中同时维护多个工作目录，每个目录可检出不同的分支或提交。这解决了多任务并行时的冲突问题。
例如，正在开发 feature/login 分支时，若需紧急修复 release/1.5 的线上 Bug，传统做法是 Stash 当前改动并切换分支，或者克隆新仓库。前者可能导致 Stash 混乱，后者环境配置繁琐。IDE 重新索引和编译也会消耗时间。
Worktree 基于同一仓库创建独立工作目录，共享 .git/objects，但拥有独立的 HEAD、index 和工作区文件。
实战场景
- 紧急修复：在项目根目录下创建新 worktree 检出目标分支。
git worktree add ../hotfix-1.5 release/1.5
此命令会在上级目录创建 hotfix-1.5 文件夹，检出 release/1.5 分支。修完 Bug 提交推送后，返回原工作目录继续开发，无需切分支或 Stash。
- 历史版本验证：创建临时工作目录检出特定提交。
git worktree add --detach ../temp-check 4f1e2c3
--detach 参数表示不关联任何分支，直接检出某个提交（分离头指针状态）。在此目录测试验证后删除即可，不影响原工作目录。
- 代码评审：为 PR 创建独立 worktree，拉取代码、跑测试、查看效果，用完即删。
注意事项与避坑
-
分支独占性：同一分支不能同时在多个 worktree 中检出。若已检出
main分支，另一 worktree 尝试检出会报错branch 'main' already checked out。如需多处查看相同提交，可使用--detach或创建不同分支指向同一提交。 -
清理记录：直接删除目录不会自动清除 Git 仓库中的 worktree 记录（位于
.git/worktrees）。正确做法是使用remove命令：
git worktree remove ../hotfix-1.5
若已手动删除目录，可用 prune 清理无效记录：
git worktree prune
建议删除前先用 list 查看，定期运行 prune -n -v 检查残留。
- 目录组织：建议将 worktree 集中管理，如在项目根目录旁建立
.wt文件夹。
git worktree add .wt/feature-x -b feature/x origin/main
git worktree add .wt/hotfix-1.5 release/1.5
局限性
- 配置共享：Worktree 共享底层
.git配置，无法设置独立的 hooks 或全局配置，此类需求仍需 Clone 独立仓库。 - Submodule 支持：对 Submodule 的支持尚不完善，需谨慎使用。
- 团队协作：若团队成员不熟悉 Worktree，可能引起目录结构困惑，推广前需统一规范。
总结
Worktree 的核心价值在于简化并行工作流。它让每个任务成为独立目录，互不干扰，避免了频繁切换分支带来的环境保存和索引重建成本。对于需要频繁在多分支间切换、维护多版本或验证历史问题的场景，Worktree 能显著提升效率。这也解释了为何 Cursor 2.0 的多 Agent 模式选择此技术实现独立代码空间。