resolving-merge-conflicts

在动手前先确认当前状态。通过 git status 判断你正处于合并、变基还是挑拣提交过程中。在变基过程中，ours 指你正在变基到的上游，而 theirs 指你自己的提交，恰好与合并时相反。弄反这一点是最常见的错误解决方式。

然后将冲突文件分类处理。根据源文件重新生成生成的产物和锁文件，绝不要手动合并它们。这包括 bun.lock、pnpm-lock.yaml、_generated/ 和快照。只有手写文件才需要执行步骤 2–3。

找出每个冲突对应的主要来源。弄清每项更改的原因和原始意图。阅读提交消息，查看 PR，以及原始问题和工单。

根据主要来源解决每个冲突块，而不是根据冲突标记。保留双方的意图。如果两者不兼容，选择符合合并既定目标的一方，并注明取舍。解决结果中的每一行都必须能追溯到一方的原始内容，或双方的机械式组合。

暂存前，针对每个冲突文件，将解决结果分别与两个父提交进行差异比较。运行 git diff --cc <file>，或运行 git diff :2:<file> <file> 和 git diff :3:<file> <file>。将双方的每个冲突块都准确归入以下某一类：保留、已被取代并注明取代内容，或已删除并注明删除原因。无法归类的冲突块就是悄然丢弃，属于披着已解决外衣的未解决冲突。提交前说明这份记录。

务必解决冲突。如果双方意图确实不兼容，且既定目标无法帮助做出选择，请停止操作，并将两种候选解决方案交给用户，而不是擅自猜测。

运行项目的检查。/done 负责整个流程。让它选择验收检查项、逐项验证、分配状态并生成就绪卡片。停在该卡片处，不要执行其最后部分列出的任何后续操作。合并过程中提交会以生成的约定式主题结束合并，而非使用合并消息，因此 git-commit 和 file-pr 都要等到步骤 5 再执行。修复合并导致的所有问题。

完成合并或变基。如果操作会改写已发布或已被使用的提交或引用，请在继续该已发布历史操作或更新其共享引用之前，立即调用 preflight-mutations。传入准确的操作、本地、上游、基准和头部 SHA，受影响的远程引用、依赖分支和 PR、恢复引用，以及明确的改写授权。继续操作前，按其结果契约执行。未发布的本地冲突解决无需经过此检查。

暂存所有内容并提交。如果正在变基，继续操作，直至所有提交都重放完毕。同一冲突经常会在每个重放的提交中再次出现，因此解决方式必须始终保持一致。