Git Worktree 解决了什么问题
传统的 git checkout 像一台老式收音机，同一时间只能收听一个频道。想换分支？先停掉当前工作，切换过去，可能还要重新 npm install 或编译一遍。
Git Worktree 的做法完全不同。它允许你从同一个 .git 仓库出发，在文件系统里同时检出多个分支，每个分支对应一个独立的工作目录。它们共享同一份 commit 历史，但文件状态互不干扰。关掉一个工作目录（git worktree remove），对其他目录毫无影响。
一句话概括：把"时间上串行"的分支切换，变成"空间上并行"的多目录共存。
以 Issue 为单位的并行开发流程
实操层面，核心思路是在项目内部创建一个专用目录存放所有 worktree，再用 .gitignore 隔离它。
假设你今天需要同时处理 issue-12（修 bug）和 issue-13（新功能），流程如下：
1. 创建并忽略 worktree 专用目录
在项目根目录创建一个 worktrees 文件夹，然后将它添加到 .gitignore。
这里有个巧妙之处：把 worktrees 目录加到 .gitignore，是防止这个"容器目录"本身被 Git 跟踪。而里面的每一个 worktree（比如 worktrees/issue-12）都是 Git 直接管理的完整工作区，内部的文件跟踪和提交完全不受影响。主干保持干净，每个分支又能独立做版本控制。
2. 为每个 Issue 创建独立工作区
用 git worktree add 为每个任务创建对应的 worktree，全部存放在 worktrees 目录中。
3. 多线程开战
cd worktrees/issue-12，创建fix/issue-12分支，启动一个 Claude Code 实例开始修 bug- 不用等它干完——立刻
cd worktrees/issue-13，创建feat/issue-13分支，启动另一个 Claude Code 实例开发新功能
每个目录维持自己独立的分支和文件状态，你可以随时在目录间切换。
4. 处理 Review 反馈
issue-12 的 Review 意见回来了？cd worktrees/issue-12，上下文瞬间恢复。改完提交、更新 PR，再 cd worktrees/issue-13 回去继续主线。整个过程没有任何等待和状态切换的开销。
VS Code 中的实操步骤
在 VS Code 里操作会更直观：
- 在 Source Control 基础上，安装 Git Worktree Manager 插件
- 通过插件面板快速创建和管理多个工作目录
- 在新建的工作目录上右键，选择 "Add folder to workspace"——这一步是关键，确保每个 Claude Code 实例都在对应的独立工作目录下运行
- 在 Explorer 面板中打开某个 worktree 目录的文件，启动 Claude Code 实例，此时实例的工作目录会被正确设置为该 worktree
- 让 Claude Code 在对应目录中完成开发，提交 commit
- 打开 Git History 面板会发现，虽然开了多个工作目录，但分支的提交情况和传统的
git checkout单目录切换完全一致——后续按常规合并机制处理即可 - 任务完成后做清理：从 workspace 中移除工作目录，再删除对应的 worktree
这件事为什么值得现在关注
正是这种并行运行多个 Claude Code 实例的能力，导致了前段时间的 Claude Code 限量风波——有开发者利用 git worktree 7x24 小时跑多个实例，单月 token 消耗高达数万美元。Anthropic 不得不出手限制。
从产品架构的角度看，这套工作流的底层逻辑和 Git 诞生之初要解决的"人类分布式协同"问题完全一致。Pull request、worktree，本质上都是隔离、并行、集成的协作模式。区别只是协作对象从人变成了 AI agent。
对独立开发者来说，这意味着一个人真的可以同时推进多条产品线。不是比喻，是字面意义上的并行开发。瓶颈不再是编码速度，而是你能不能把任务拆得足够清晰、把 context 给得足够准确——说白了，就是管理能力。这条路径目前没有技术壁垒，Git Worktree 谁都能用，真正的差距会体现在谁能把"一人指挥多 AI 执行"这套协作模式跑得更顺畅。