Conventional Commits 规范详解：1.0.0-beta.4 版本指南
2025-07-07 02:56:24作者：晏闻田Solitary
什么是 Conventional Commits
Conventional Commits 是一种轻量级的提交信息规范，它为开发者提供了一套明确的提交信息编写规则。这套规范的主要目的是创建清晰的提交历史记录，便于自动化工具处理，同时与语义化版本控制（SemVer）完美配合，通过提交信息准确描述功能更新、错误修复和重大变更。
核心规范解析
提交信息基本结构
提交信息应当遵循以下格式：
<类型>[可选范围]: <描述>
[可选正文]
[可选页脚]
主要组成部分说明
-
类型（Type）：
fix：表示修复代码中的错误（对应 SemVer 中的 PATCH 版本）feat：表示新增功能（对应 SemVer 中的 MINOR 版本）- 其他可选类型：如 chore、docs、style、refactor、perf、test 等
-
范围（Scope）（可选）：
- 用括号括起来的名词，表示修改的代码范围
- 示例：
feat(parser): 添加数组解析功能
-
描述（Description）：
- 对变更的简短描述
- 使用命令式现在时态（如"add"而非"added"或"adds"）
-
正文（Body）（可选）：
- 提供变更的详细说明
- 与描述之间需要空一行
-
页脚（Footer）（可选）：
- 包含元信息，如关联的问题、重大变更等
- 每行一个元信息
重大变更（BREAKING CHANGE）
重大变更必须以下列方式之一标明：
- 在正文开头使用
BREAKING CHANGE:前缀 - 在页脚中使用
BREAKING CHANGE:前缀 - 在类型/范围后添加
!符号（同时仍需包含 BREAKING CHANGE 说明）
实际应用示例
包含描述和重大变更的提交
feat: 允许配置对象继承其他配置
BREAKING CHANGE: 配置文件中extends键现在用于继承其他配置文件
使用!标记重大变更
chore!: 从测试矩阵中移除Node 6支持
BREAKING CHANGE: 停止支持将于四月终止维护的Node 6
简单文档更新
docs: 修正CHANGELOG的拼写
带范围的特性提交
feat(语言支持): 添加波兰语支持
修复问题的提交
fix: 修正代码中的小拼写错误
详见问题描述中的具体拼写错误
关联问题 #12
规范细节要点
- 提交必须包含类型前缀，后接可选范围和必需的冒号加空格
feat类型必须用于新增功能fix类型必须用于错误修复- 范围是可选的，但使用时必须用括号括起
- 描述必须紧跟类型/范围前缀
- 正文必须在描述后空一行开始
- 页脚必须在正文后空一行开始
- 重大变更必须明确标明
- 除
feat和fix外，可以使用其他类型 - 信息单元不区分大小写，但 BREAKING CHANGE 必须大写
- 可以在类型/范围前缀后添加
!来突出重大变更
使用 Conventional Commits 的优势
- 自动生成变更日志：工具可以根据规范的提交信息自动生成详细的变更日志
- 自动确定版本号：根据提交类型自动决定语义化版本号的更新方式
- 清晰沟通变更：团队成员和其他利益相关者可以清楚地了解每次变更的性质
- 触发构建流程：规范的提交信息可以作为自动化流程的触发器
- 降低贡献门槛：结构化的提交历史使新贡献者更容易理解项目
常见问题解答
如何处理开发初期的提交信息？
建议像已经发布产品一样处理提交信息。即使只有团队成员在使用你的代码，他们也需要知道修复了什么、有什么变化等信息。
类型应该大写还是小写？
大小写都可以，但建议保持一致。
如果提交符合多个类型怎么办？
尽可能拆分为多个提交。Conventional Commits 的一个优势就是促使我们做出更有组织的提交。
这会阻碍快速开发和迭代吗？
不会阻碍快速开发，但会阻止无序的快速变更。长期来看，它有助于在多个项目和贡献者之间保持高效的开发节奏。
规范是否会限制开发者只做特定类型的提交？
规范鼓励多做一些如修复类的提交，但也足够灵活，允许团队定义自己的类型并根据需要调整。
如何与SemVer对应？
fix对应 PATCH 版本feat对应 MINOR 版本- 包含
BREAKING CHANGE的提交对应 MAJOR 版本
提交类型写错了怎么办？
在合并或发布前，可以使用 git rebase -i 修改提交历史。发布后的处理方式取决于你使用的工具和流程。
所有贡献者都需要遵守这个规范吗？
不必。如果使用基于压缩（squash）的工作流，维护者可以在合并时清理提交信息，不会给临时贡献者增加负担。
