根据Conventional Commits规范，合并冲突解决提交类型应如何选择？

Conventional Commits规范里并没有专门用于标记“解决合并冲突”的提交类型，这类提交的类型需要根据冲突涉及的代码变更性质来判断，以下是对应场景的选择建议：

• 若冲突仅涉及文档（比如README、注释、接口文档）：使用docs类型，示例：docs: resolve merge conflicts in user API docs
• 若冲突涉及业务功能代码的调整：根据代码实际作用选feat（新增/迭代功能）或fix（修复bug），示例：feat: resolve merge conflicts for cart checkout feature、fix: resolve merge conflicts in order status error handling
• 若冲突与工具链、构建配置、依赖管理相关：使用chore类型，示例：chore: resolve merge conflicts in package.json dependency versions
• 若冲突涉及代码格式、lint规则调整：使用style类型，示例：style: resolve merge conflicts in eslint configuration
• 若冲突来自重构代码的合并：使用refactor类型，示例：refactor: resolve merge conflicts in user module refactoring

如果一次冲突解决涉及多种类型的变更，优先选择占比最大、最核心的变更对应的类型；如果是零散无明确归类的小冲突，也可以用chore作为兜底，但建议尽量精准匹配变更性质。

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