关于Git提交规范

自古至今，无规矩不成方圆。

Git提交也有其规范，业内做的比较好的，比较具有参考价值的就是Angular的提交。

Angular提交规范:

<type>(<scope>): <subject> #header

// 空一行

<body>

// 空一行

<footer>

格式讲解

Header

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

总的来说，关键就是header这部分，至于<body>和<footer>可省略

例如:

feat:新增财务报表

type

用于说明本次commit的类别，只允许使用下面7个标识

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

注意:如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

scope

用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

subject

是 commit 目的的简短描述，不超过50个字符。

以动词开头，使用第一人称现在时，比如change，而不是changed或changes

第一个字母小写

结尾不加句号（.）

反面示例1:

不要像如下这样提交，显得可笑（反面示例，以示警戒）

上面就是一部门功能，按照angular这种提交规范，应该要这样:

feat:完成部门管理功能

当然了，这样提交信息是叫完成部门管理功能,肯定是要包含上述的什么分页，新增，修改，删除等等的。没有必要这么写一大堆罗里吧嗦的。

反面示例2:

这个提交信息让人觉得太泛。你提交的信息是财务，财务有很多功能啊，比如财务报表，其中报表又分月报表和日报表，报表中还有支出报表和收入报表等等。

上述的提交缺点是信息不明确，太泛。

反面示例3:

删除文件，同样也是信息不明确，不过这个人犯的错误是实际删除了一个Java类，当然了，Java类也是一个文件，不过这里让人很疑惑，你到底删除了几个类啊或者是其他文件呢？你光就一个提交信息，说删除文件，鬼知道你删除了多少文件。

既然是删除文件，你可以这样提交信息:

del:删除cn.test包下的Test.Java

这样与上面对比，岂不是简洁的多。

当然了，实际中，也不一定要采用Angular这种，但是你可以借鉴它的，然后自己那边再根据实际情况变动。

提交规范在于以后维护方面是非常有利的，先不说远的，近的话，使用Git时，合并代码通常会有冲突，有些突发意外，比如另外的人不小心将你的代码覆盖了，而且这个功能已经是很久之前的了，那怎么办呢？通常情况，本地有备份固然好，但是估计也没有那个人会将自己每次提交，都本地保存一份，因为那样显得效率低下和根据项目的周期和需求，项目越来越大，这样的话，本地备份的包也会越来越多。没有人会选择这种方式。最后的方式就是版本回退，当然了，前提是你提交信息必须简洁明了，不然的话像上面的反面例子，鬼知道是哪个。

另外关于什么时候，提交，尽可能是完成一个新的功能或者是优化某个功能，解决某个bug等等就提交。但是这里有个前提就是，你本地必须测试没有问题，否则那样等于做无用工。

希望这篇文章能给大家带来帮助。