开发团队中，总是有人提交代码时的commit内容不明确、不完整。当其他人回溯代码时，很难通过commit内容定位历史记录，无法确定时，只能咨询参与开发的其他同事，沟通成本很高。定义commit规范能够一定程度解决这个问题，但是规范一定要简单，过于严苛和复杂会让提交者厌烦。

如果您的团队采用tapd作为敏捷开发平台，可以参考这套规范：
示例：TAPD需求标题：类型：主题
解释：

1. 内容由3个部分构成：TAPD需求标题、类型标识和主题，中间用全角或者半角逗号分隔。
2. 如果TAPD标题很长，可以截取前10到15位，TAPD标题必须填写。
3. 类型列表：

类型	缩写	解释	必填
feature	fea	新功能开发	否
fixbug	fix	修复BUG	是
test	test	测试用例	是
refactor	ref	重构，即不是新功能也不是修改bug	是
build	build	影响构建或外部依赖项	是
style	style	修改了代码格式	是
doc	doc	修改了文档	是
other	oth	其他的修改	是

示例一：新功能开发
开发需求“订单满1000元送优惠券”，commit范例如下：
订单满1000元送优惠券：fea：判断订单金额` 或者 `订单满1000元送优惠券：判断订单金额

由于新功能开发是常态，fea可以省略不写。如果发现某个地方有优化的空间，但是与本次需求无关，commit范例如下：
订单满1000元送优惠券：ref：优化了订单查询性能

示例二：解决BUG
需求“订单满1000元送优惠券“已上线，后来发现bug，commit范例如下：
订单满1000元送优惠券：fix：修复重复赠送优惠券的问题

其他几种类型，就不一一列举了，这个规范的特点是：通过commit历史找到TAPD任务标题，进而找到的需求详细内容，回溯业务逻辑。

本文链接：https://www.codingbrick.com/archives/313.html
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。