Resolving Merge Conflicts —— 解决 Git 合并冲突的技能

技能概述

Resolving Merge Conflicts 是一个让 AI 代理接手进行中 merge 或 rebase 冲突的技能：它先看清仓库状态和冲突文件，再追溯每处改动的来源与原始意图，逐块消解冲突并尽可能保留双方目标，最后跑通项目检查、暂存并提交，把合并真正做完。

适用场景

1. 多人协作分支合并出现冲突：两个分支都改了同一批文件，git merge 卡在冲突状态，需要有人读懂双方改动再决定怎么合，而不是随手挑一边。

2. PR 合并前的冲突处理：拉取主干后发现 PR 分支与主干冲突，需要在不破坏主干行为的前提下把自己的改动接上去，同时说明无法同时保留时的取舍。

3. 长期分支 rebase 到主干：rebase 往往会在多个提交上连续产生冲突，技能要求逐个提交解决并持续 --continue，直到整个 rebase 流程走完，而不是停在中间。

核心功能

1. 先看状态，再动代码：检查 git 历史与冲突文件，明确当前处于 merge 还是 rebase、哪些文件冲突、涉及哪些提交，避免在没搞清状况时就开始改文件。

2. 追溯冲突的原始意图：为每处冲突找出主要来源——读提交信息、翻 PR、查原始 issue 或工单，弄清楚每一侧当初为什么这么改，再决定如何消解。

3. 逐块消解并保留双方目标：能同时保留两边意图的就保留；确实互斥时，选与本次合并目标一致的那一侧，并记录下取舍。技能明确要求不发明新行为，也明确要求不使用 --abort——冲突始终是被解决的，不是被绕过的。

4. 跑通自动化检查后收尾：发现项目自带的检查流程（通常是类型检查 → 测试 → 格式化），修复合并破坏的部分，然后暂存全部改动并提交；如果是 rebase，则继续推进直到所有提交都完成变基。

常见问题

解决冲突时可以直接 git merge --abort 放弃吗？

不可以。这个技能把"始终解决、绝不 abort"写成了硬性要求。放弃合并只是把冲突推迟给下一个人，还会丢失已经理清的上下文。真正该做的是搞清双方意图后把冲突消解掉。

rebase 过程中解决完一处冲突后怎么继续？

rebase 与 merge 不同：它可能对每一个被变基的提交都产生一次冲突。解决完当前这轮的冲突、跑完检查后，需要按 rebase 流程继续（git rebase --continue），并重复处理后续提交的冲突，直到整个 rebase 结束——而不是解决一次就当作完成。

怎么知道每处冲突的改动是谁、为什么改的？

技能要求回到一手来源：查看提交信息、对应的 PR、以及最初的 issue 或工单。弄清每一侧的原始意图之后，才能判断两处改动是能共存，还是必须二选一。

双方改动都合理、无法同时保留时该怎么选？

优先尝试同时保留两边意图；只有在确实不兼容时，才选择与本次合并既定目标一致的那一侧，并把这次取舍明确记下来。技能不允许为了"让冲突消失"而自行发明原本不存在的逻辑。

解决完冲突要跑哪些检查？

技能会先发现项目自己的自动化检查流程，典型顺序是类型检查、测试、格式化。凡是合并弄坏的地方都要修好，确认通过后再暂存提交。

它适用于哪些工具？

这是一个面向 AI 编程代理的技能文件（SKILL.md 形式），在支持技能机制的编程助手中生效，例如 Claude Code。它约束的是代理处理冲突时的行为方式，本身不依赖特定语言或框架，任何使用 git 的项目都可以用。

冲突很多时会不会漏掉某一处？

技能的第一步就是列出全部冲突文件，第三步要求逐个 hunk 消解，收尾阶段还要跑检查兜底。相比"挑几处改完就提交"，这套流程更不容易留下未处理的冲突标记。