关于 merge-branch
merge-branch 是用于审查并将分支变更整合到共享主线的技能。它强调依据项目原则评估变更、明确产品决策与风险，并在合并后验证；除非收到要求，否则不推送。
主要功能
- 01检查提交记录与相关差异
- 02依据项目原则审查变更
- 03标出意图不明之处与潜在缺陷
- 04产品或高影响决策前先询问
- 05验证合并结果并记录决策
适用场景
- 01整合长期分支前进行审查
- 02处理影响产品行为的冲突
- 03推送前检查已合并的变更
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/merge-branch确认已加载。
详细介绍
合并分支
合并是更改进入共享主线的时刻，因此也兼作评审关卡。在更改合入之前，应根据项目明示的原则（如果有 PRINCIPLES.md、AGENTS.md、CONTRIBUTING.md 或类似文件）评判这些更改。
绝不要擅自做出产品决策。 解决冲突或评审更改时，可能会悄然决定客户看到什么或产品如何运行——哪种行为胜出、哪条流程得以保留。如果遇到这种情况，请停下来询问用户最终的客户体验应该是什么。说明你的理由并建议一种解决方案——由用户决定。
大影响范围的事项也一样。 如果解决冲突需要重塑架构、数据或领域模型，或更改依赖项——这些事项一旦进入共享主线，回退成本就很高——就不应在合并过程中擅自决定。先询问。
用简单的话询问。 每个问题只涉及一项决策，用通俗语言表达，先给出你的建议，再说明每个选项对客户意味着什么。绝不要把多个决策捆绑成一个问题，也绝不要在问题仍未解决时继续合并。
记录答案。 用户在合并过程中做出的每项产品决策都要写入合并提交消息：问题是什么、选择了哪个选项，以及原因。之后查看 git log 的人不应还得自行还原这些信息。
下文中，<main> 是主集成分支（例如 main 或 dev）。
合并前
- 了解即将合入的内容。 运行
git log --oneline <target>..<branch>和git diff --stat <target>...<branch>，然后阅读重要的差异块。 提交消息应清楚说明每项更改的意图——如果无法从差异和提交消息中看清意图，就应询问，而不是猜测。 - 对照原则进行评审。 尤其要注意：
- 简单胜于复杂。 引入不必要复杂性的更改——并行机制、现有内容的第二份副本、通用容器——应在合并前指出并讨论，而不是等合并后再处理。
- 潜在的 Bug 来源。 留意常见问题：重复状态、时间戳比较、在响应用户的线程上执行阻塞 I/O、按字节处理文本、未本地化的字符串。
- 如果目标分支面向另一平台，则应询问每项即将合入的更改在该平台上意味着什么，并在合并提交中或项目跟踪平台适配工作的地方记录哪些内容无法迁移，而不是让它们悄然变成无操作。
- 先报告发现。 列出分支中的更改、任何不明确之处，以及任何与原则相冲突的内容。由用户决定某项发现是否会阻止合并，或作为后续工作处理。
选择合并方向
如果先将 <main> 合并到另一个分支更容易，就应说明——不要先把该分支合并到 <main>。 如果分支长期存在或预计会有冲突，通常应采用这种方式：将 <main> → 分支，在问题影响范围有限的分支上解决冲突并验证，然后再将（现已无冲突的）分支 → <main>。说明你建议的方向及理由，并让用户确认。
合并
- 通过理解双方意图来解决冲突，绝不要机械地选择一方。如果冲突揭示同一内容被构建了两次，这是一项发现，而不只是一个冲突。
- 在合并提交消息中记录用户在整个过程中做出的每项产品决策，以及用户选择作为后续工作处理的任何发现。
- 合并后进行验证：构建、运行与更改规模相称的测试，并明确说明验证了什么、未验证什么。
- 除非用户要求，否则不要推送。