规范的作用

大多数情况下，看提交历史的人跟提交代码的人都不是同一个人，当别人阅读你的提交历史时，他很可能是不知道具体代码细节的，你如何在最短的时间内让他一眼知道每次提交的意义：

• 每次提交影响的具体范围？
• 这个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#