规范的作用
大多数情况下，看提交历史的人跟提交代码的人都不是同一个人，当别人阅读你的提交历史时，他很可能是不知道具体代码细节的，你如何在最短的时间内让他一眼知道每次提交的意义：
- 每次提交影响的具体范围？
- 这个bug在哪次提交中被修复了？
- 这个新功能是在哪次提交中增加的？
- 修改是否向下兼容？
- 是否回滚了代码？
- 是否只是修改了文档、调整了代码格式？
- 是否修改了测试、是否进行了重构？
- 是否对代码进行了性能优化？
这些都是提交规范的作用。
代码复查/审查
良好的Git提交日志非常重要，最明显的一点是，它让整个Git提交历史的阅读变得非常轻松：
一眼看上去，就知道每个提交是做了什么，是加了新功能，还是修改了bug，是维护了文档，还是调整了单元测试，都一目了然。
生成CHANGELOG
而且规范的Git提交历史，还可以直接生成项目发版的CHANGELOG（semantic-release）：
AngularJS的开发指南中已经对Git的提交日志做了明确规范，这种规范几乎适用于所有项目，本文搬运过来，粗糙翻译，与君共享。
规范细则
对于Git的提交日志，我们有非常明确而详细的提交规范。这将有助于我们在查看项目历史时，更容易明确每一次提交的内容。另一方面，我们还直接使用了Git提交日志来生成AngularJS的变更日志。
Git的提交日志可以通过常用的Git工作流或向导工具(Commitizen)来生成。如果你选择使用Commitizen，那只需要在Git暂存修改后，执行“yarn run commit”命令即可。
提交消息格式
每个提交消息都由一个标题、一个正文和一个页脚组成。而标题又具有特殊格式，包括修改类型、影响范围和内容主题：
修改类型(影响范围): 标题
<--空行-->
[正文]
<--空行-->
[页脚]标题是强制性的，但标题的范围是可选的。
提交消息的任何一行都不能超过100个字符！这是为了让消息在GitHub以及各种Git工具中都更容易阅读。
修改类型
每个类型值都表示了不同的含义，类型值必须是以下的其中一个：
- feat：提交新功能
- fix：修复了bug
- docs：只修改了文档
- style：调整代码格式，未修改代码逻辑（比如修改空格、格式化、缺少分号等）
- refactor：代码重构，既没修复bug也没有添加新功能
- perf：性能优化，提高性能的代码更改
- test：添加或修改代码测试
- chore：对构建流程或辅助工具和依赖库（如文档生成等）的更改
代码回滚
代码回滚比较特殊，如果本次提交是为了恢复到之前的某个提交，那提交消息应该以“revert:”开头，后跟要恢复到的那个提交的标题。然后在消息正文中，应该写上“This reverts commit <hash>”，其中“<hash>”是要还原的那个提交的SHA值。
影响范围
范围不是固定值，它可以是你提交代码实际影响到的任何内容。例如$location、$browser、$compile、$rootScope、ngHref、ngClick、ngView等，唯一需要注意的是它必须足够简短。
当修改影响多个范围时，也可以使用“*”。
标题
标题是对变更的简明描述：
- 使用祈使句，现在时态：是“change”不是“changed”也不是“changes”
- 不要大写首字母
- 结尾不要使用句号
正文
正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句且现在时态，正文应该包含更详细的信息，如代码修改的动机，与修改前的代码对比等。
页脚
任何Breaking Changes（破坏性变更，不向下兼容）都应该在页脚中进行说明，它经常也用来引用本次提交解决的GitHub Issue。
Breaking Changes应该以“BREAKING CHANGE:”开头，然后紧跟一个空格或两个换行符，其他要求与前面一致。
最后说一句
人生苦短，请遵守规范。
参考链接
https://github.com/angular/angular.js/commits/master
https://github.com/angular/angular.js/blob/master/CHANGELOG.md
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines
https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
