git commit message规范
2021-01-17 本文已影响0人
lzhenboy
1、背景
在使用git时，每次代码提交都需要写commit message作为git log以便于项目管理。
然而在日常的团队开发中，每个人的commit message千奇百怪，规范不一致，中英文混合使用等问题，会导致项目git log格式混乱、不便维护。因此，构建一份结构清晰、简洁优雅的commit message规范不仅有助于高效管理项目、降低维护成本，也方便团队成员之间review、提高研发效率。
2、commit message规范
<type>[(<scope>)]: <subject>
其中，<type> 和 <subject>是必填项，(<scope>)是选填项
下面对这三个模块详细阐述：
2.1 type
type用于声明本次代码提交的类型（英文，必填项），通常是在满足一个技术和业务域需求的条件下的团队约定的有限集合，便于成员统一共识，不宜太多导致类型太散、不便记忆，也不宜太少，无法有效区分。
从算法团队角度出发，将类型限定在如下集合：
feat：新功能特性。
fix：bug修复。
perf：功能优化，包括性能优化、体验优化等。
refactor：代码重构（大范围的代码结构重构，不涉及代码功能）
style：格式调整（小范围的代码格式调整，不涉及代码功能）
merge：代码分支合并
revert：代码版本回滚
test：测试代码变动
doc：文档变动
2.2 scope
scope用于声明本次代码提交的影响范围（建议英文，选填项），如Model层、Dao层、Service层、Controller层、View层等等。
如果涉及多个scope，可以置空或用*代替。
2.3 subject
subject用于声明本次代码提交的描述信息（建议中文，必填项）。
通常控制在50个字符内，且省略句末标点符号。
以上是一些基本的 commit message规范，项目的复杂性和业务域不同，可能会有不同的调整或补充，就以上规范，列举几个示例如下：
feat(Controller):商品属性识别接口开发
fix(Service):入参边界检查条件不足
