git commit 原则

多人开发时少不了代码review的环节，这时候commit显得尤为重要，

优质的代码提交和简单清晰的common可以让review的人用最短的时间

完成review，以下是我总结的一些commit遇到和需要注意的问题供大家参考。

 

commit是给review的人看的。

review的人具备一定的技术背景；都很忙。

所以commit要尽可能用最少的语言将问题表达清楚。

 

 

一、commit格式，主题 + 内容，中间用行隔开

 

[主题] “这是一个动作，描述做了什么改动，解决哪些问题。”

 

* 长度尽可能短，一句话。

* 能清楚完整的描述本次提交。（不能泛泛而谈，更不能不知所云）

* 动作尽量放在前面，（add、remove、fix、merge、update ...）

 

[内容] “描述问题现象，分析问题原因，阐述解决办法”

 

* 描述复杂的话可以将bugid或issureid的链接贴上

* 内容根据修改的复杂程度酌情填写，主题可以描述清楚的，内容可不写，如添加几个字符串，加几个log什么的

* 如果主题中有多个逻辑修改，这里要每个进行单独描述并分段隔开

 

自定义格式：

 

[fix bug bugid] + 描述

[add feature] + 描述

[fix issue issueid] + 描述

[Merge] + 描述

 

.......

 

二、commit粒度

 

粒度受到产品阶段的影响，不同阶段提交粒度不同，研发阶段可根据功能和框架特征提交。维护阶段细分case后进行提交。但总的原则要保证commit的精简和功能独立。

 

* 维护阶段保证一个问题只做一次commit

* 一次commit对逻辑性文件的修改越少越好

* 多个小case进行一次提交的情况，内容部分对每个case分段描述（不建议）

* merge代码单独做commit。