引言
:
即每次进行 Git 提交时，需要编写的提交说明。
:
* 创建清晰、结构化的提交历史
* 编写自动化工具
* 直接生成 changelog
* 基于提交的类型，自动决定语义化版本（SemVer）变更
* 让后续代码审查、信息查找、版本回退都更加高效可靠
* ...
:
1. Angular 提交信息规范
> 最初由前端框架 `Angular` 开发团队推出并内部使用，随后逐渐得到肯定和推广
2. [Atom 提交规范](https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages)
> `Atom` 编辑器项目使用的提交规范
3. [Conventional Commits](https://www.conventionalcommits.org/zh-hans/v1.0.0/)（约定式提交）
> 由 Angular 提交信息规范衍生而来
4. [ESLint 提交规范](https://eslint.org/docs/latest/contribute/pull-requests#step-2-make-your-changes)
> `ESLint` 工具项目使用的提交规范
5. 自定义规范
> 基于主流规范，结合自身业务场景定制提交规范规范细则
🫧 Important
我们基于 Conventional Commits（约定式提交）约束团队的 Git 提交信息，罗列约束条款如下
核心格式
plaintext
<类型>[可选 作用域]: <描述>
[可选 正文]
[可选 脚注]: 必须提供的字段，用于描述提交的性质。您可以指定如下类型之一：
| 类型 | 描述 | 备注 |
|:--------:|----------------------------------------------------------------------|----------------------------|
| fix | 在代码库中修复了一个 bug | 这和语义化版本中的 `PATCH` 相对应 |
| feat | 在代码库中新增了一个功能、特性 | 这和语义化版本中的 `MINOR` 相对应 |
| docs | 修改文档 | 例如修改 README 文件、API 文档等 |
| style | 修改代码的样式 | 例如调整缩进、空格、空行等 |
| refactor | 重构代码 | 例如修改代码结构、变量名、函数名等但不修改功能逻辑 |
| perf | 优化性能 | 例如提升代码的性能、减少内存占用等 |
| test | 修改测试用例 | 例如添加、删除、修改代码的测试用例等 |
| build | 修改项目构建系统 | 例如修改依赖库、外部接口或者升级 Node 版本等 |
| chore | 对非业务性代码进行修改 | 例如修改构建流程或者工具配置等 |
| ci | 修改[持续集成](https://www.redhat.com/zh-cn/topics/devops/what-is-ci-cd)流程 | 例如修改 Travis、Jenkins 等工作流配置 |
> ⚠️ **BREAKING CHANGE**
>
>
> 在 ***脚注 (footer)*** 中包含 `BREAKING CHANGE:` 或 \<类型\>\[作用域\] 后面有一个 `!` 的提交，表示引入了破坏性的 API 变更（这和语义化版本中的 `MAJOR` 相对应）。破坏性变更可以是任意 ***类型 (type)*** 提交的一部分。: 可选字段，用于说明提交影响的范围（如模块、组件、功能点，如 auth、payment）。
: 必须提供的字段，用于间接描述提交内容（通常不超过 50 字符，首字母小写，结尾不加标点符号）。
: 可选字段，详细描述提交的动机、修改内容等，可换行。
: 可选字段，用于标注不兼容变更（BREAKING CHANGE: ...）或关联 Issue（如 Closes #123）
约定式提交规范
💡 Tip
以下内容中的关键词：
- 必须 (MUST)
- 禁止 (MUST NOT)
- 必要 (REQUIRED)
- 应当 (SHALL)
- 不应当 (SHALL NOT)
- 应该 (SHOULD)
- 不应该 (SHOULD NOT)
- 推荐 (RECOMMENDED)
- 可以 (MAY)
- 可选的 (OPTIONAL)
其相关解释参考 RFC 2119。
- 每个提交都 必须 使用类型字段前缀，它由一个名词构成，诸如
feat、fix等等，其后接 可选的 作用域，可选的!，以及 必要 的冒号（英文半角）和空格。 - 当一个提交为应用或类库实现了新功能时，必须 使用
feat类型。 - 当一个提交为应用修复了 bug 时，必须 使用
fix类型。 - 作用域字段 可以 跟随在类型字段后面。作用域 必须 是一个描述某部分代码库的名词，并用圆括号包围，例如
fix(parser):。 - 描述字段 必须 紧跟在 <类型>[作用域] 前缀的冒号和空格之后。描述指的是对代码变更的简短总结，例如 fix: 当字符串中包含多个空格时的数组解析问题。
- 在简短描述之后，可以 编写较长的提交正文，为代码变更提供额外的上下文信息。正文 必须 起始于描述字段结束的一个空行后。
- 提交的正文内容自由编写，并 可以 使用空行分隔不同段落。
- 在正文结束的一个空行之后，可以 编写一个或多个脚注。每个脚注都 必须 包含一个令牌（token），后面紧跟
:<空格>或<空格>#作为分隔符，后面再紧跟令牌的值（受 git trailer convention 启发）。 - 脚注的令牌 必须 使用
-作为连字符，例如Asked-by（这有助于区分脚注和多个段落正文）。有一种例外情况是BREAKING CHANGE，其 可以 被认为是一个令牌。 - 脚注的值 可以 包含空格和换行，值的解析过程 必须 直到下一个脚注的令牌/分隔符对出现为止。
- 破坏性变更 必须 在提交信息中标记出来，要么在 <类型>[作用域] 前缀中标记，要么作为脚注的一项。
- 如果作为脚注的一项标记，则破坏性变更 必须 包含大写文本
BREAKING CHANGE，后面紧跟冒号、空格和描述，例如 BREAKING CHANGE: 环境变量现在优先于配置文件。 - 如果在 <类型>[作用域] 前缀中标记，则破坏性变更 必须 通过在紧挨
:前的!标记出来。如果使用了!，那么脚注中 可以 省略BREAKING CHANGE:，同时提交信息的描述中 应当 描述破坏性变更。 - 在提交信息中，可以 使用
feat和fix之外的类型，例如 docs: 更新了 ref 文档。 - BREAKING-CHANGE 作为脚注的令牌时 必须 是
BREAKING CHANGE的同义词。
示例
包含了描述和破坏性变更脚注的提交信息
plaintext
feat: 允许提供的配置对象扩展其他配置
BREAKING CHANGE: 配置文件中的 `extends` 键现在用于扩展其他配置文件包含了 ! 以提醒注意破坏性变更的提交信息
plaintext
feat!: 当产品发货时向客户发送电子邮件包含了作用域和 ! 以提醒注意破坏性变更的提交信息
plaintext
feat(api)!: 当产品发货时向客户发送电子邮件同时包含了 ! 和 BREAKING CHANGE 脚注的提交信息
plaintext
chore!: 停止对 Node 6 的支持
BREAKING CHANGE: 使用在 Node 6 中不可用的 JavaScript 功能不包含正文的提交信息
plaintext
docs: 纠正 CHANGELOG 拼写包含了作用域的提交信息
plaintext
feat(lang): 添加波兰语包含了多段正文和多个脚注的提交信息
plaintext
fix: 防止请求竞态
引入请求ID和最新请求的引用。忽略来自最新请求之外的响应。
移除用于缓解竞态条件问题的超时设置，其已经过时。
Reviewed-by: Z
Refs: #123FAQ
参考
[1] 约定式提交
[2] Conventional 提交规范 - Git Guide