现状
开发团队中，总是有人提交代码时的commit内容乱写一通，或者不明确不完整。当回溯代码的时候，很难通过commit内容定位历史记录，只能一条一条查看，找不到就要去问历史参与开发的其他同事，沟通成本太高了。定义commit规范，能够一定程度解决这个问题，规范一定要简单，过于严苛和复杂会让提交者厌烦。如果您的团队采用tapd作为敏捷开发平台，可以参考这套规范。
规范
示例：
TAPD需求标题：类型：主题
解释：
- 内容由3个部分构成：TAPD需求标题、类型标识和主题，中间用全角或者半角逗号分隔。
- 如果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的内容回溯业务逻辑。