基于tapd的git commit规范

现状

开发团队中，老是有人提交代码时的commit内容乱写一通，或者不明确不完整。当回溯代码的时候，很难经过commit内容定位历史记录，只能一条一条查看，找不到就要去问历史参与开发的其余同事，沟通成本过高了。定义commit规范，可以必定程度解决这个问题，规范必定要简单，过于严苛和复杂会让提交者厌烦。若是您的团队采用tapd做为敏捷开发平台，能够参考这套规范。

规范

示例：
TAPD需求标题：类型：主题

解释：

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

类型列表：

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

示例1：新功能开发

开发需求“订单满1000元送优惠券”，commit范例以下：

订单满1000元送优惠券：fea：判断订单金额 或者 订单满1000元送优惠券：判断订单金额

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

示例2：解决BUG

需求“订单满1000元送优惠券“已上线，后来发现bug，commit范例以下：

订单满1000元送优惠券：fix：修复重复赠送优惠券的问题

其余几种类型，就不一一列举示例了，这个规范的特色是：经过commit历史找到对应的tapd，经过tapd的内容回溯业务逻辑。