Git提交规范
1. 为什么 commit message 要规范化
在团队协作开发时，我们一般都会使用 Git 版本控制工具来管理代码，每个人提交代码时都会写 commit message。
如果没有一个规范的话，每个人都会有自己的书写风格, 最后可以说是五花八门，十分不利于阅读和维护。
一般来说，大厂都有一套的自己的提交规范，尤其是在一些大型开源项目中，commit message 都是十分一致的。
因此为了后期工作的顺利，我们需要制定统一标准，使得提交记录清晰明了，让人一看就能知道此次提交的目的。本文将探讨业界使用得最多的 Git 提交规范。
2. 格式
<type>[scope]:<subject>
// 空一行
[body]
// 空一行
[footer]
注：[] 代表可选，<> 代表必填。
3. type
必填，用于指定 commit 的类型。
| type | 说明 |
|---|---|
feat |
增加新功能 |
fix |
修复 bug |
docs |
只改动了文档相关的内容 |
style |
格式修改，没有修改代码逻辑，比如格式化、换行等 |
refactor |
重构代码，既没有新增功能，也没有修复 bug，比如提取某段代码为一个方法、重构某个功能等 |
perf |
性能、体验优化等 |
test |
新增 test 用例或修改现有测试用例 |
build |
构造工具的或者外部依赖的改动，比如 maven |
ci |
与 CI ( 持续集成服务 ) 有关的改动 |
chore |
不修改 src 或者 test 的其余修改，例如构建过程或辅助工具的变动 |
revert |
执行 git revert 打印的 message |
当同时有 feat、fix 和其他类型时，类型取 feat、fix。
4. scope
非必填，用于描述改动的范围，格式一般为项目名/模块名，如果一次 commit 修改多个模块，建议拆分成多次 commit，以便更好追踪和维护。
5. subject
必填，此次提交的简短描述，动词开头，第一人称现在时，比如 add，而不用 added、adds，第一个字母小写，句尾不加句号 (.)
6. body
非必填，此次提交的详细描述，主要描述改动之前的情况及修改动机，对于小的修改不作要求，但是重大需求、更新等必须添加 body 来作说明。
7. footer
footer 只用于以下两种情况
break changes
break changes 指明是否产生了破坏性修改，涉及 break changes 的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等，以 BREAKING CHANGE： 开头，后面是变动的描述、变动的理由以及迁移的方法。
- 关闭 issue
当前提交修改了某个 issue
以下取自开源项目 angular 的一次 commit message：
fix(ngStyle): correctly remove old style when new style value is invalid
Since d6098ee, old styles were not removed if `newStyles` specified an
invalid value for the style (e.g. `false`). The assumption was that the
new style would overwrite the old style value, but using an invalid
value made browsers ignore the new value and thus keep the old style.
This would typically happen when guarding a style with a boolean flag;
e.g.: `ng-style="{backgroundColor: isError && 'red'}"`
This commit essentially revers commit d6098ee, whose main purpose was
to work around jquery/jquery#4185. The jQuery issue has been fixed in
3.4.0, so that should not be a problem any more.
Fixes #16860
Closes #16868
