Conventional Commits 规范详解：提升Git提交信息的标准化实践

什么是Conventional Commits

Conventional Commits是一种Git提交信息的标准化规范，它通过定义统一的提交信息格式，帮助开发团队更好地理解代码变更内容、自动生成变更日志(ChangeLog)以及实现语义化版本控制(SemVer)。

核心规范解析

基础提交格式

提交信息必须遵循以下基础结构：

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

[可选正文]

[可选页脚]

主要提交类型

1. fix：修复bug的提交，对应语义化版本中的PATCH版本号变更
2. feat：新增功能的提交，对应语义化版本中的MINOR版本号变更
3. BREAKING CHANGE：任何包含此标记的提交都表示有破坏性变更，对应MAJOR版本号变更

其他推荐类型

虽然规范仅强制要求fix和feat两种类型，但实践中推荐使用以下扩展类型：

• chore：构建过程或辅助工具的变动
• docs：文档变更
• style：代码格式调整（不影响代码逻辑）
• refactor：代码重构
• perf：性能优化
• test：测试相关变更
• improvement：现有功能的改进（非新功能也非bug修复）

详细规范说明

1. 类型前缀：必须使用名词作为类型前缀，后跟冒号和空格
2. 范围限定：可选部分，用于说明变更影响的具体模块，用括号包裹
3. 描述部分：必须简明扼要地说明变更内容
4. 正文部分：可提供更详细的变更说明，必须与描述部分空一行
5. 页脚部分：可包含问题追踪编号或破坏性变更说明，必须与正文空一行
6. 破坏性变更：必须在正文或页脚开头明确标注"BREAKING CHANGE: "并说明具体变更

实际应用示例

带破坏性变更的提交

feat: 允许配置对象继承其他配置

BREAKING CHANGE: 配置文件中extends键现在用于继承其他配置文件

简单文档更新

docs: 修正CHANGELOG的拼写错误

带范围的特性提交

feat(国际化): 新增波兰语支持

修复特定问题的提交

fix: 修复代码中的小拼写错误

详见问题描述中的详细错误列表

修复问题 #12

为何要采用Conventional Commits

1. 自动化变更日志：可根据提交信息自动生成规范的变更记录
2. 版本控制自动化：基于提交类型自动确定版本号变更级别
3. 团队协作透明化：使团队成员清晰了解每次变更的性质
4. 构建流程触发：可作为自动化构建和发布的触发条件
5. 降低贡献门槛：结构化的提交历史便于新贡献者理解项目

常见问题解答

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

建议从一开始就采用规范，即使项目尚未发布。团队成员也需要了解每次变更的具体内容。

提交涉及多种变更类型怎么办？

尽可能拆分为多个提交。规范的提交有助于保持代码变更的原子性和可追溯性。

会降低开发速度吗？

短期看可能需要适应，但长期看能提高跨项目协作的效率。规范带来的结构化和清晰度最终会提升整体开发速度。

会限制提交类型吗？

规范鼓励使用特定类型（如fix/feat），但也允许团队自定义其他类型并随时间调整。

与SemVer的关系？

• fix → PATCH版本
• feat → MINOR版本
• BREAKING CHANGE → MAJOR版本

提交类型写错了怎么办？

合并前：使用git rebase -i修改提交历史 合并后：根据团队流程处理，工具可能会忽略不符合规范的提交

最佳实践建议

1. 为项目编写提交信息模板，降低团队成员的学习成本
2. 在CI流程中添加提交信息校验，确保规范被遵循
3. 结合自动化工具自动生成变更日志和版本号
4. 对于大型团队，可以考虑使用交互式工具辅助生成规范提交信息
5. 定期回顾提交历史，优化类型和范围的使用方式

通过采用Conventional Commits规范，团队可以显著提升代码管理的规范性和自动化程度，为项目的长期健康发展奠定基础。