specsfy-specialist-merge-conflict-resolution

解决冲突

适用场景

• 当 git merge、git rebase 或 git cherry-pick 已在进行中，且有文件被标记为 unmerged 时触发。
• 不要用来决定在产品层面应该由哪个分支的修改胜出——这是发起集成者的决定；此技能负责解决文本和最终行为，不会重新审议业务决策。
• 解决后与 $specsfy-specialist-code-review 配合使用——合并后的结果需要接受与任何新 diff 相同的审查。

流程

1. 检查操作的确切状态（merge、rebase、cherry-pick）、涉及哪些分支/提交，以及哪些文件处于 unmerged 状态。
2. 对每个冲突块，找出双方的意图——也就是修改试图实现什么，而不只是字面文本。
3. 对冲突进行分类：文本冲突（同一行，文本不同）、结构冲突（同一函数/代码块被重新组织）、语义冲突（没有文本标记，但行为不兼容——例如一方修改了函数签名，另一方却没有调整调用方）或生成文件冲突（lockfile、构建文件）。
4. 如果双方的意图兼容，就构造一个能保留双方意图的结果——正确的解决方式很少是直接选择整一边。
5. 如果双方的意图确实不兼容，则根据集成目标做出选择（即促成此次集成的规范/issue 所要求的内容），并记录被舍弃的权衡。
6. 移除所有冲突标记，验证文件的语法/解析结果，并对已修改的文件运行重点检查（lint、typecheck）。
7. 继续操作（git merge --continue/git rebase --continue），并在发布前运行相关回归测试套件。

准则

• 绝不要为了方便而批量使用 git checkout --ours/--theirs（或策略性解决方式 -X ours/-X theirs）——每个冲突块都可能有不同的正确解决方式；应用全局策略会在未经审查的情况下丢弃一方的实际修改。
• 不要编辑生成文件（lockfile、构建输出、生成代码），除非同时更新生成它的源文件并重新生成——直接编辑生成文件会导致它在下次生成时出现差异。
• 如果双方的 schema 修改、migrations、测试和 API 契约并未真正冲突，就保留双方的修改——相邻文件中的冲突不意味着可以丢弃另一个文件中的 schema 修改。
• 即使文件中没有文本冲突标记，也要重新检查 imports、重命名和调用——一方重命名，而另一方仍使用旧名称，不会产生 Git 冲突，却会导致运行时或构建失败。
• 除解决冲突严格必要的内容外，不要引入新行为——解决冲突不是重构的机会。
• 未经负责集成的人员明确要求，不要使用 --abort、force push 或破坏性 reset——进行中的操作可能包含其他人已经完成的冲突解决工作。
• 继续操作前，最后确认没有文件仍处于 unmerged 状态，且索引干净。

反模式

• 只以“能编译”为标准解决冲突：文件没有冲突标记且构建成功，但从未将最终行为与任一方的意图进行比较——语义冲突会伪装成已解决而继续存在。
• 未与其他协作者协调，就通过 rebase 重写已经发布并共享的提交——这会悄无声息地破坏他人的历史记录。
• 不逐个审查，就一次性解决大型文件中的所有冲突块——这会增加因疲劳而接受错误冲突块的可能性。
• 依赖 git rerere 重复之前的解决方式，却不再次确认周边上下文是否已发生足以使已记录解决方案失效的变化。

验证

• git status 中没有未合并文件，且任何文件中都没有残留冲突标记（在工作目录中用 grep 搜索 <<<<<<<）。
• 已逐个 hunk 对照从双方意图重建的内容，审查合并后的 diff。
• 已运行所触及文件的类型检查、构建和针对性测试，以及与集成后行为相关的回归测试套件。
• 发布前已确认最终历史记录和推送目标（分支、是否强制推送）——如果历史记录已重写，未经此项检查，绝不发布冲突解决结果。
• 没有这些证据，就不要宣称集成“已解决”——未经重新构建和测试验证的解决结果只是没有冲突标记，并不能证明正确。

相关技能

• $specsfy-specialist-code-review：像审查任何新 diff 一样审查合并结果，因为冲突解决可能引入原始 PR 单独来看未覆盖的行为。
• $specsfy-specialist-domain-modeling：当语义冲突表明双方对同一领域概念的建模不兼容时使用——冲突是边界未对齐的症状。
• $specsfy-specialist-gitflow：当声明采用 Gitflow 的项目中，涉及 feature/、release/ 或 hotfix/ 的合并或变基发生冲突时使用——该技能决定分支拓扑和合并目标，本技能则解决已经出现的文本或语义冲突。

请阅读 references/standards.md，了解诊断命令、没有文本标记的冲突类型，以及 Git 官方资料来源。