关于代码提交规范聊两点,第一是 注意提交的原子性,第二是 提高提交说明的质量(Commit Message)
一、 提高提交的原子性
很多程序员提交代码喜欢「憋大招」写完一堆功能、 或开发完成后,才提交一次代码,这个行为会造成很多不好的后患:
- 一次性提交太多,代码审核人员无力仔细审查
- 出现问题无法快速定位问题
- 如果出现问题,只有大面积回滚及功能下架
- 没有合理做任务、 功能拆分,对风险控制不能做合理预估
- ...
所以提出了「代码提交的原子性」来规避以上问题
代码提交的原子性是指:一个提交包含一个不可分割的特性、 功能、修复或者优化,同时这个提交要尽可能小
原子性提交的优点是:结构清晰、 容易定位问,一般来说,代码提交的原子性做得越好,代码质量越好,同时,原子性提交因为小而聚焦,也是做好代码审查的基础
多大算大,多小算小?
通过最近一段时间的摸索,我给出的边界是,一句话,能清晰的描述本次提交的所有修改信息,这一次提交就是一个合理的原子提交
二、 提高提交说明的质量(Commit Message)
很多人怕麻烦,提交说明非常简短,很多只包含一句话,比如,功能提交常常写个 实现A、 B功能；Bug 修复提交有些更简单，通常就三个字母 fix ,针对这个情况,真的是让人头疼,对于审核人员不清楚本次提交的意图、 如果出现了异常,不能快速定位问题源以及不知回滚到哪一次提交点
提交说明是提高代码审查的利器，好的格式应该包含以下几个方面：
类型:我喜欢把它叫做提交前缀,你为什么会提交这次代码? 大致会有几个可能性:新功能开发、 Bug修复、 注释编写或调整文档编写或调整、 删除或整理冗余代码、 初始化仓库、 其他 → 分别对应前缀 feat、 fix、 doc、 refactor、 init、 other,代码审核人员或协同人员,可以根据 前缀 快速高效的明白你本次提交的意图,根据不同的意图,确定查阅的策略和重点关注区域
标题简要:用一句话简要清晰的描述出本次的变更内容
详情描述:如果 标题简要 描述不清,那就需要用 详情描述 做补充(这个方式我个人是不建议的),一般描述更多的是对 标题简要的 其他方面做补充,比如:修改了哪些文件、 会影响哪些范围、 对应的任务ID等信息
示例如下:
feat:微信支付完成
fix:修复了微信支付不成功问题
1. 微信支付回调地址修改为 https 类型
2. 微信支付价格调整为以 分 为单位
前缀和标题简要 这部分最好在70个字符之内,以确保在单行显示的时候能够显示完整,比如,在命令行常用的 git log --oneline输出结果要能显示完全
对于提交信息不规范我们可以统一配置 .gitmessage 文件模板,来降低标准差,确保统一
对于提交原子性,我们可以通过内部沟通、 内部培训、 让大家的编码综合水平提升、 编程思想升华、 对功能拆分、 任务拆分的粒度逐渐找到感觉
