Conventional Commits 规范详解：提升项目提交信息的标准化

什么是Conventional Commits

Conventional Commits（约定式提交）是一种用于规范Git提交信息的轻量级约定，它通过标准化的提交信息格式，帮助开发团队更好地理解代码变更内容、自动生成变更日志(CHANGELOG)以及确定语义化版本号(SemVer)的升级策略。

核心规范解析

基本提交格式

约定式提交的基本格式如下：

<类型>[可选范围]: <描述>

[可选正文]

[可选页脚]

主要提交类型

1. fix：表示修复了一个bug（对应语义化版本中的PATCH版本升级）
2. feat：表示新增了一个功能（对应语义化版本中的MINOR版本升级）

破坏性变更

任何包含BREAKING CHANGE:的提交（无论类型是fix还是feat）都表示引入了不兼容的API变更（对应语义化版本中的MAJOR版本升级）。

破坏性变更可以出现在提交正文或页脚的开头位置。

可选范围

范围(scope)用于提供额外的上下文信息，放在类型后的括号内，例如： feat(parser): 增加解析数组的能力

详细规范要求

1. 类型前缀：必须使用类型前缀，后跟冒号和空格
2. 描述要求：描述必须紧跟在类型/范围前缀之后
3. 正文格式：正文必须在描述后空一行开始
4. 页脚格式：页脚必须在正文后空一行开始
5. 其他类型：除fix和feat外，可以使用其他自定义类型（如docs、style等）

为什么使用约定式提交

1. 自动生成变更日志：工具可以自动从标准化的提交信息中生成CHANGELOG
2. 自动版本管理：根据提交类型自动确定语义化版本升级策略
3. 改善团队协作：清晰的提交历史帮助团队成员理解变更内容
4. 自动化流程：可以触发构建和发布流程
5. 降低贡献门槛：结构化的提交历史让新贡献者更容易理解项目

常见问题解答

初期开发阶段如何处理提交信息？

建议从一开始就采用约定式提交，就像产品已经发布一样。即使只有团队成员在使用，他们也需要知道修复了什么、有什么变化。

提交符合多种类型怎么办？

尽可能拆分为多个提交。约定式提交的一个优势就是促使我们做出更有组织的提交。

这会阻碍快速开发和迭代吗？

不会阻碍快速开发，而是避免混乱无序的开发方式。长期来看，它有助于在多个项目和贡献者之间保持高效协作。

如何与语义化版本(SemVer)对应？

• fix类型对应PATCH版本
• feat类型对应MINOR版本
• 包含BREAKING CHANGE的提交对应MAJOR版本

提交类型用错了怎么办？

1. 使用了规范内但不正确的类型（如用fix代替feat）：在合并或发布前，建议使用git rebase -i编辑提交历史
2. 使用了规范外的类型（如feet代替feat）：最坏情况下，这类提交只会被基于规范的工具忽略

最佳实践建议

1. 保持提交的原子性，每个提交只做一件事
2. 描述要简洁但信息完整
3. 对于复杂变更，使用正文详细说明
4. 破坏性变更必须清晰标注并说明影响
5. 团队可以扩展自定义类型，但要保持一致性

通过采用Conventional Commits规范，开发团队可以显著提升提交信息的可读性和实用性，为自动化工具提供结构化数据，最终提高项目的可维护性和协作效率。