用Git工作树隔离并行AI开发任务

Git worktree 解决的是一个很具体的麻烦：手头的代码还没写完，又要切分支修 Bug，或者想让几个 AI 编程会话同时干活。它让同一个仓库拥有多个工作目录，每个目录使用自己的分支，省掉反复 stash、切换、恢复现场的折腾。

作者把这套机制延伸到了 Claude Code：一个任务对应一个 worktree 和一个分支，再分别审查、合并。但目录分开只是第一步，依赖、环境变量、端口和数据库仍要另外安排。这些细节，决定了并行开发究竟省事还是添乱。

多个目录为什么能共用一个仓库

先分清三个东西：branch 是指向提交的指针，worktree 是检出代码的目录，stash 用来暂存尚未提交的改动。它们各有用途，并不是三选一。

普通 clone 得到的目录是 main worktree，额外添加的是 linked worktree。各目录拥有自己的文件、HEAD 和暂存区（index），同时共享仓库历史、分支、标签和远程配置。因此，一个目录产生的提交，在其他目录也能看到。

下面三条命令分别解决已有分支、新建分支和临时实验的问题：

git worktree add ../project-hotfix hotfix/login-bug
git worktree add -b feature-x ../project-feature-x main
git worktree add -d ../scratch

注意第二行末尾的 main，它指定新分支的起点；第三行的 -d 则创建 detached HEAD，也就是不绑定分支的检出状态。

省略 commit-ish，又没有指定 -b、-B 或 --detach 时，Git 会用目录名作为分支名，必要时从 HEAD 创建。如果名称只匹配一个远程的跟踪分支，还会按 add --track -b 的方式处理。

默认情况下，同一个分支不能同时检出到两个 worktree。虽然 --force 可以绕过检查，作者建议另建分支。这个建议合理：目录各自独立，分支引用却是共享的，让两个目录同时推动同一分支，会增加状态混乱的机会。

共享配置也有类似边界。refs/heads/*、refs/tags/* 共享，HEAD、index 和 refs/bisect/* 按目录独立，所以可以在一个目录里 bisect，不打扰另一个。仓库配置默认共享；需要单独设置 core.sparseCheckout 等选项时，要启用 extensions.worktreeConfig，再使用 git config --worktree。原文提醒，旧版 Git 可能拒绝打开启用该扩展的仓库，但没有给出版本范围。

Claude Code 自动安排了什么，还留下什么

按原文转述的文档，Claude Code 提供 --worktree，简写是 -w。下面的命令会创建工作目录，并在其中启动会话：

claude --worktree feature-auth

注意 feature-auth 是此次 worktree 的名字。默认目录是仓库根目录下的 .claude/worktrees/<name>/，新分支叫 worktree-<name>。省略名字时会自动生成，例如 bright-running-fox；仓库必须先有至少一个提交，文档还建议把 .claude/worktrees/ 加入 .gitignore。

分支起点尤其容易误判。按原文描述，worktree.baseRef 默认是 "fresh"，从远程默认分支起步；设成 "head"，才会从当前本地 HEAD 起步。当前目录里的改动，不能想当然地当作新任务的起点。

会话中也可以要求 Claude「work in a worktree」，由 EnterWorktree 工具完成切换。传入 claude --worktree "#1234"，则会获取该 PR 的 head，放进 .claude/worktrees/pr-<number>。偏好手动管理的人，也能先执行 git worktree add ../project-feature-a -b feature-a，进入目录后再运行 claude。

这里有两个前端项目很容易踩到的坑：

第一，node_modules、构建产物和 virtualenvs 不会跟着出现，新目录需要安装依赖。第二，被忽略的 .env、.env.local 也不会自动复制。Claude Code 可以读取项目根目录的 .worktreeinclude，按 .gitignore 语法，把列出的忽略文件复制到它创建的 worktree；依赖安装仍需自己执行，或交给 Claude。

退出时，干净且未命名的会话会自动删除 worktree 和分支；有工作内容时，Claude 会询问保留还是删除。不要把这一条理解成所有会话都会自动清理。

并行 Agent 的收益，取决于任务怎么拆

作者给出的模式很直接：每个 Agent 会话使用独立 worktree、独立分支，各自测试和提交，再按普通 PR 审查合并。例如，在两个终端分别启动 claude --worktree fix-login-bug 和 claude --worktree add-export-csv。

Worktree 隔开的是文件编辑现场，合并冲突仍由任务之间的重叠决定。

如果两个任务都改同一个文件，最终仍可能冲突。先挑改动范围不同的任务，比单纯多开会话更重要。子代理也支持这一安排：可以要求 Claude「use worktrees for your agents」，或在自定义子代理的 frontmatter 中设置 isolation: worktree；临时 worktree 在没有改动的情况下会自动移除。

运行环境则需要另管。两个开发服务器都占用 3000，仍然会抢端口；共用本地数据库，也可能互相影响。Worktree 不是机器隔离机制，Agent 执行 cp 往主目录写文件，也不会仅因使用 worktree 就被阻止。

清理同样需要建立习惯。用 git worktree list 查看目录、提交短哈希和分支，输出还会标记 locked、prunable；-v 显示锁定原因，脚本宜用稳定格式的 --porcelain，路径可能含换行时再加 -z。

删除优先用 git worktree remove <path>。有未跟踪文件或已修改文件时，需要 --force；锁定目录需要两次 --force，主 worktree 不能删除。手动 rm -rf 会留下 $GIT_DIR/worktrees 管理记录，可用 git worktree prune -v 清理，-n 先预演，--expire 限定过期时间，也可等待 gc.worktreePruneExpire 对应的自动清理。

移动目录使用 git worktree move，手动移动后用 git worktree repair 修复关联。外接盘、网络盘等可能暂时离线的目录，可以用 git worktree lock --reason "on external drive" <path> 防止管理记录被清理。子模块支持则有明显限制：原文引用手册称多检出仍属实验性，含子模块的 worktree 删除需要 --force，也不能通过 move 移动。

我的判断

作者说得最扎实的部分，是把「多个编辑现场」和「多个运行环境」分开讨论。对前端、Node 项目而言，创建目录很容易，补齐依赖、配置、端口和数据库安排，才算真正准备好第二个开发环境。

但原文是一份操作指南，没有提供并行 Agent 的耗时、成功率、冲突率或成本对照。开头所说的「标准方式」，应当视为作者对实践趋势的判断，不能据此推导出多开 Agent 一定提效。文中的 Claude Code 行为来自文档转述，也没有列出实测版本和完整实验记录。

与 stash 相比，worktree 更适合持续一段时间的插单任务；两分钟的临时切换，stash 可能更方便。与再次 clone 相比，它省去独立复制仓库历史，分支和提交也直接共享，但工作文件和依赖安装的成本仍在。大仓库、重度使用子模块的项目，以及任务高度重叠的场景，都需要先算这笔账。

能拿来做什么

• 正在开发功能又要修线上问题时，为修复分支创建独立 worktree，保留原目录的未提交现场；修复完成后审查提交，再删除目录。
• 给前端或 Node 项目整理一份新目录启动步骤，明确依赖安装、.env 准备、端口和本地数据库名称。使用 Claude Code 时，再用 .worktreeinclude 自动复制需要的忽略文件。
• 尝试并行 AI 编程时，先安排两个改动范围明确、尽量不碰同一文件的任务，每个会话单独测试和提交，合并前分别检查差异。
• 将目录回收纳入日常流程：先用 git worktree list 确认状态，再用 remove 删除；遇到手动删除留下的记录，先通过 prune -n 查看待清理内容。