自古至今,无规矩不成方圆。
Git提交也有其规范,业内做的比较好的,比较具有参考价值的就是Angular的提交。
Angular提交规范:
<type>(<scope>): <subject> #header // 空一行 <body> // 空一行 <footer>
格式讲解
Header
Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。
总的来说,关键就是header这部分,至于<body>和<footer>可省略
例如:
feat:新增财务报表
type
用于说明本次commit的类别,只允许使用下面7个标识
feat
:新功能(feature)fix
:修补bugdocs
:文档(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等等就提交。但是这里有个前提就是,你本地必须测试没有问题,否则那样等于做无用工。
希望这篇文章能给大家带来帮助。
本文转载自:
关于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
:修补bugdocs
:文档(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等等就提交。但是这里有个前提就是,你本地必须测试没有问题,否则那样等于做无用工。
希望这篇文章能给大家带来帮助。
本文转载自: