用 Codex 在多个 worktree 里写代码，最后怎么合？

用 Git worktree 可以同时开几个目录，让 Codex 在不同分支上各做一件事。干活的时候挺方便，到了合并这一步，之前分开做的事情又得放到一起看。

比如，一个分支改了公共函数的参数，另一个分支在别的文件里加了一处调用。Git 可能直接就合过去了，因为两边改的是不同文件。但新加的调用还在用旧参数，跑起来才会发现问题。

如果 Codex 在一次任务里还顺手改了命名、格式，或者搬了几段代码，合并时要看的东西就更多了。即使只冲突了几行，也可能得把前后几个提交翻出来，才能看懂两边为什么这么写。

让 AI 合并，先让它读懂两边的改动

我现在会把合并单独当成一个任务交给 Codex。先让它从两个分支的共同起点看起，弄清楚各自加了什么、修了什么，再动手处理冲突。

比如一边把某个检查挪到了公共函数里，另一边在原来的位置补了一个边界条件。直接选一边，可能就把另一边的修复丢了。更合适的做法是看那个边界条件在新结构里该放哪儿，再用合并后的代码跑一下对应测试。

还有一步容易漏掉：只有一边改过的文件，也可以和原分支核对一遍。大多数文件应该能原样带过来。如果合并时又改了其中某个文件，就说清楚这次为什么需要跟着改。这样回头审合并结果时，比较容易找到真正需要看的地方。

把合并流程做成一个 Codex Skill

开几个 worktree 并行写代码，每次收尾都要合分支。与其每次重新交代怎么查两边的改动、怎么解冲突、合完跑什么测试，我更愿意把这套流程跟代码一起维护。

把下面的内容保存到仓库的 .agents/skills/worktree-merge/SKILL.md。下次在要接收改动的 worktree 里打开 Codex，说「用 $worktree-merge 把 feature/example 合进当前分支」就行。把示例分支名换成你实际要合进来的分支。

---
name: worktree-merge
description: 在 Git worktree 中合并指定分支，处理冲突，核对双方改动并验证合并后的行为。
---

# 合并 worktree 分支

1. 确认当前 worktree、接收分支和来源分支。检查是否已有合并或变基在进行，以及工作区是否有未提交改动。如果状态会影响安全合并，先说明情况并停下。
2. 找到共同祖先，分别查看两边新增的提交和文件差异。记下双方要保留的行为，重点留意公共接口、调用方和配置。
3. 从干净的工作区开始，用 git merge --no-ff --no-commit <来源分支> 生成可审阅的合并结果。遇到冲突时，结合双方的提交和测试，尽量保留两边的需求。如果双方对同一种情况要求不同的结果，列出差异，请用户决定。
4. 核对合并后的文件。只有一边改过的文件，和来源版本对一下。需要联动修改时，说明原因。即使 Git 自动合上了，也检查跨文件的接口、调用和配置是否对得上。
5. 将解决后的文件加入暂存区，确认没有未解决的冲突。运行 git diff --check 和 git diff --cached --check，再在合并后的代码上跑受影响的测试，重点验证两边放在一起才会出现的问题。
6. 汇报双方各保留了什么、冲突怎么处理、哪些检查本次跑过以及结果如何。把失败、跳过和沿用的旧结果分开写。默认将合并结果留在当前 worktree 供审阅，收到明确指示后再提交或推送。

对我来说，最值得固定下来的是第四步。一个分支改了参数，另一个分支刚好加了调用，Git 可能顺利合完，代码却跑不起来。把这一步写进 Skill，下次换一个 worktree、换一次任务，也会检查两边的改动能不能一起工作。