GIT提交规范

GIT提交规范

规范的作用

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

• 每次提交影响的具体范围？
• 这个bug在哪次提交中被修复了？
• 这个新功能是在哪次提交中增加的？
• 修改是否向下兼容？
• 是否回滚了代码？
• 是否只是修改了文档、调整了代码格式？
• 是否修改了测试、是否进行了重构？
• 是否对代码进行了性能优化？

这些都是提交规范的作用。

代码复查/审查

良好的Git提交日志非常重要，最明显的一点是，它让整个Git提交历史的阅读变得非常轻松：

一眼看上去，就知道每个提交是做了什么，是加了新功能，还是修改了bug，是维护了文档，还是调整了单元测试，都一目了然。

生成CHANGELOG

而且规范的Git提交历史，还可以直接生成项目发版的CHANGELOG（release）：

开发指南中已经对Git的提交日志做了明确规范，这种规范几乎适用于所有项目，

规范细则

对于Git的提交日志，我们有非常明确而详细的提交规范。这将有助于我们在查看项目历史时，更容易明确每一次提交的内容。另一方面，我们还直接使用了Git提交日志来生成项目的变更日志。

Git的提交日志可以通过常用的Git工作流或向导工具(Commitizen)来生成。如果你选择使用Commitizen，那只需要在Git暂存修改后，执行“yarn run commit”命令即可。

提交消息格式

每个提交消息都由一个标题、一个正文和一个页脚组成。而标题又具有特殊格式，包括修改类型、影响范围和内容主题：

type(scope) : subject

1. type（必须） : commit 的类别，只允许使用下面几个标识：

每个类型值都表示了不同的含义，类型值必须是以下的其中一个：

• feat：提交新功能
• fix：修复了bug
• docs：只修改了文档
• style：调整代码格式，未修改代码逻辑（比如修改空格、格式化、缺少分号等）
• refactor：代码重构，既没修复bug也没有添加新功能
• perf：性能优化，提高性能的代码更改
• test：添加或修改代码测试
• build : 改变了build工具 如 grunt换成了 npm
• revert : 撤销上一次的 commit
• chore：对构建流程或辅助工具和依赖库（如文档生成等）的更改

1. scope（可选） : 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。修改类型
2. subject（必须） : commit 的简短描述，不超过50个字符。commitizen 是一个撰写合格 Commit message 的工具，遵循 Angular 的提交规范。

代码回滚

代码回滚比较特殊，如果本次提交是为了恢复到之前的某个提交，那提交消息应该以“revert:”开头，后跟要恢复到的那个提交的标题。然后在消息正文中，应该写上“This reverts commit <hash>”，其中“<hash>”是要还原的那个提交的SHA值。

影响范围

范围不是固定值，它可以是你提交代码实际影响到的任何内容。例如$location、$browser、$compile、$rootScope、ngHref、ngClick、ngView等，唯一需要注意的是它必须足够简短。

当修改影响多个范围时，也可以使用“*”。

标题

标题是对变更的简明描述：

• 使用祈使句，现在时态：是“change”不是“changed”也不是“changes”
• 不要大写首字母
• 结尾不要使用句号

正文

正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句且现在时态，正文应该包含更详细的信息，如代码修改的动机，与修改前的代码对比等。

页脚

任何Breaking Changes（破坏性变更，不向下兼容）都应该在 scope 中进行说明，它经常也用来引用 本次提交解决的GitHub Issue。

Breaking Changes应该以“BREAKING CHANGE:”开头，然后紧跟一个空格或两个换行符，其他要求与前面一致。

最后说一句

人生苦短，请遵守规范。

参考文档：

AugularJS 代码提交规范