Conventional Commits：解决合并冲突应使用何种提交类型？

Conventional Commits v1.0.0核心规范里并没有专门为合并冲突解决定义专属提交类型，但社区已经形成了几种通用的实践方案，你可以根据具体场景选择：

1. 使用fix类型（最常用场景） #

如果冲突解决涉及修复代码逻辑不一致、修正合并后出现的功能异常，直接用fix类型完全符合规范：

fix: resolve merge conflicts in user authentication flow

fix类型的核心是修复代码缺陷或功能问题，合并冲突本质上是代码逻辑的冲突，解决后能确保代码正常运行，完全匹配这个类型的定义。

2. 使用chore类型（无功能变更时） #

如果冲突仅涉及注释、空行、代码格式这类不影响业务功能的内容，用chore类型更合适：

chore: resolve merge conflicts in README and config files

chore用于标记不影响用户体验的工程类变更，正好对应这类无业务逻辑改动的冲突解决场景。

3. 自定义merge类型（团队约定优先） #

如果你的团队有统一的内部约定，可以扩展规范新增merge类型，比如：

merge: resolve conflicts between feature/payment and develop branches

但要注意，自定义类型必须确保团队所有成员都认可并遵循，避免提交信息混乱。

关键原则

• 优先匹配现有规范里的标准类型，尽量不随意扩展，保证提交信息的通用性
• 提交描述要明确说明冲突涉及的模块或功能，方便后续代码追溯

内容的提问来源于stack exchange，提问作者Stepan