让 AI 编程任务各用一个目录：Git worktree 的创建、验收与收尾

一个任务在修改页面，另一个任务在补测试，如果它们操作同一个目录，交付时容易混进彼此的改动。可以先为任务划定分支和目录，再让每个任务在自己的位置工作。

Git worktree 允许一个仓库拥有多个工作目录，分别检出不同分支；这些目录共享仓库对象，但拥有各自的 HEAD 和索引等状态。[1] 本文依据 Git 官方手册整理，资料核对日期为 2026 年 10 月 19 日。

先约定任务，而不是先开目录

本文建议每个任务开始前写清四件事：

目录不同只能减少直接修改同一份文件的情况，不能代替任务边界。两个任务如果同时重构同一个接口，最后仍需协调设计和合并。

从明确的提交创建两个 worktree

先在现有仓库检查：

1git status --short
2git worktree list
3git rev-parse HEAD
复制

确认当前 HEAD 就是本次希望采用的起点，再执行：

1git worktree add -b codex/docs-pass ../demo-docs HEAD
2git worktree add -b codex/test-pass ../demo-tests HEAD
3git worktree list
复制

-b 创建新分支，末尾的 HEAD 明确了提交起点。[1] 这里选的是当前提交；如果希望基于其他提交或分支，应先核对再替换，不能默认它就是远端主分支。

目标路径和分支名都要唯一。原目录尚未提交的文件变更不会因为选择 HEAD 就自动出现在新目录中；需要带入的改动应另行审阅和保存。

给每个任务写一段位置明确的说明

可以把下面的模板用于文档任务：

工作目录为 ../demo-docs，预期分支为 codex/docs-pass。先验证目录和分支，读取适用项目指令，仅修改 docs/ 内与安装说明有关的文件。运行现有文档检查，交付修改摘要、实际验证结果与 git diff。不要操作另一个任务目录。

测试任务同样应说明自己的目录、分支与目标。开始时让 Agent 报告实际位置，比在最后发现改错目录更容易处理。

本文建议先交给每个任务一个小改动，确认定位正确，再扩大范围。若使用的应用已有托管 worktree 功能，应遵循应用的创建与清理流程，避免手工移动它管理的目录。

文件分开后，运行资源还要分开

worktree 不是容器，也不隔离网络、数据库和外部账号。本文建议再检查：

• 两个开发服务器是否争用同一端口；
• 测试是否写入同一个数据库或输出目录；
• 生成产物和缓存是否被硬编码到公共路径；
• 本地配置与依赖是否需要按项目约定分别准备。

例如，让两个测试任务使用不同测试库，或明确限制它们只跑不会写共享状态的检查。共享资源的责任需要写进任务说明，不能由目录名称推断。

合并前，分别看成果

在两个 worktree 中分别执行：

1git status --short
2git diff --stat
3git diff
复制

本文建议先检查是否出现任务范围以外的文件，再看实际验证结果。每个任务都应能独立解释自己的改动，之后才按项目流程提交、评审和整合。

有冲突时，先判断两个任务是否修改了同一行为或约定。只把冲突标记删掉、让文件能保存，还不能证明整合后的结果正确。

收尾时保留可恢复的成果

Git 提供 git worktree remove 移除关联工作目录。默认仅允许移除干净的 worktree；存在修改或未跟踪文件时，会拒绝删除。[1]

确认成果已提交或另行可靠保存，重要的忽略文件也已检查后，再从其他目录执行：

1git worktree remove ../demo-docs
2git worktree remove ../demo-tests
3git worktree list
复制

移除目录后，分支仍可按项目流程处理。不要把强制删除当作例行收尾；遇到拒绝时，先查明有哪些文件需要保留。

参考来源

本文为原创整理。任务边界、交付模板和共享资源检查为作者建议；命令未在读者仓库执行。

• [1] Git 官方手册：git-worktree