1. fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。
2. feat: 类型 为 feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
3. BREAKING CHANGE: 在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交，表示引入了破坏性变更（这和语义化版本中的 MAJOR 相对应）。破坏性变更可以是任意 类型 提交的一部分。对于 fix:、feat: 和 chore:，乃至更多其它的 类型 而言，它都是有效的。
4. 其它在 fix: 和 feat: 之外的提交 类型 也都是支持的，例如 Angular 约定 中推荐使用 docs:、style:、refactor:、perf:、test:、chore:，但这些标签在约定式提交规范中并不是强制性的。

其他标签含义：

docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
1
2
3
4
5

约定式提交规范

本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 RFC 2119 的描述解释。

1. 每个提交都必须使用类型字段前缀，这由一个形如 feat 或 fix 的名词组成，其后接冒号和空格。
2. 当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
3. 当一个提交为应用修复了 bug 时，必须使用 fix 类型。
4. 可选的作用域字段可以在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 fix(parser): 等。
5. 描述字段必须紧接在类型或作用域前缀之后。描述指的是对代码变更的简短描述，形如 fix: array parsing issue when multiple spaces were contained in string.
6. 在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
7. 在正文结束的一个空行后，可以编写脚注（如果正文缺失，可以编写在描述之后）。脚注应当为代码变更包含额外的 issue 引用信息（例如它所修复的 issue，类似 Fixes #13 等）。
8. 破坏性变更必须在提交的正文或脚注加以展示。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，紧跟冒号和空格。
9. 在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如 BREAKING CHANGE: environment variables now take precedence over config files.
10. 脚注必须只包含 BREAKING CHANGE、外部链接、issue 引用和其它元数据信息。
11. 在提交说明中，可以使用 feat 和 fix 之外的类型。

为什么使用约定式提交

1. 自动化生成 CHANGELOG。
2. 基于提交的类型，自动决定语义化的版本变更。
3. 向同事、公众与其他利益关系人传达变化的性质。
4. 触发构建和部署流程。
5. 让人们更容易地探索结构化的提交历史，降低贡献项目的难度。