多人开发时少不了代码review的环节，这时候commit显得尤为重要，
优质的代码提交和简单清晰的common可以让review的人用最短的时间
完成review，以下是我总结的一些commit遇到和需要注意的问题供大家参考。
commit是给review的人看的。
review的人具备一定的技术背景；都很忙。
所以commit要尽可能用最少的语言将问题表达清楚。
一、commit格式，主题 + 内容，中间用行隔开
扫描二维码关注公众号，回复：
367386 查看本文章
[主题] “这是一个动作，描述做了什么改动，解决哪些问题。”
* 长度尽可能短，一句话。
* 能清楚完整的描述本次提交。（不能泛泛而谈，更不能不知所云）
* 动作尽量放在前面，（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。