引言
Git 提交信息即每次进行 Git 提交时，需要编写的提交说明。简要、清晰、规范的 Git 提交信息有助于：
- 创建清晰、结构化的提交历史
- 编写自动化工具
- 直接生成
changelog - 基于提交的类型，自动决定语义化版本（SemVer）变更
- 让后续代码审查、信息查找、版本回退都更加高效可靠
主流 Git 提交信息规范
- 自定义规范：基于主流规范，结合自身业务场景定制提交规范
- ESLint 提交规范：
ESLint工具项目使用的提交规范 - Conventional Commits（约定式提交）：由 Angular 提交信息规范衍生而来
- Atom 提交规范：
Atom编辑器项目使用的提交规范 - Angular 提交信息规范：最初由前端框架
Angular开发团队推出并内部使用，随后逐渐得到肯定和推广
规范细则
重要提示
团队通常基于 Conventional Commits（约定式提交）约束团队的 Git 提交信息，罗列约束条款如下
核心格式
<类型>[可选 作用域]: <描述> [可选 正文] [可选 脚注]
类型 (type)
必须提供的字段，用于描述提交的性质。您可以指定如下类型之一：
| 类型 | 描述 | 备注 |
|---|---|---|
| fix | 在代码库中修复了一个 bug | 这和语义化版本中的 PATCH 相对应 |
| feat | 在代码库中新增了一个功能、特性 | 这和语义化版本中的 MINOR 相对应 |
| docs | 修改文档 | 例如修改 README 文件、API 文档等 |
| style | 修改代码的样式 | 例如调整缩进、空格、空行等 |
| refactor | 重构代码 | 例如修改代码结构、变量名、函数名等但不修改功能逻辑 |
| perf | 优化性能 | 例如提升代码的性能、减少内存占用等 |
| test | 修改测试用例 | 例如添加、删除、修改代码的测试用例等 |
| build | 修改项目构建系统 | 例如修改依赖库、外部接口或者升级 Node 版本等 |
| chore | 对非业务性代码进行修改 | 例如修改构建流程或者工具配置等 |
| ci | 修改持续集成流程 | 例如修改 Travis、Jenkins 等工作流配置 |
BREAKING CHANGE
在 中包含 或 后面有一个 的提交，表示引入了破坏性的 API 变更（这和语义化版本中的 相对应）。破坏性变更可以是任意 提交的一部分。
