说明
年前我需要写公司的年度工作总结，所以把项目里的提交日志拉出来查看，其中有几类提交是无效的也是没有意义的，整理起来十分蛋疼，所以记录下来。
示例
只有操作类型
fix
add
上面这两个可以知道是修复功能和添加功能，但是需要看代码才能知道修复的是什么，添加的是什么。
提交说明使用外文进行说明
fix refund
英文不好的人可能看到英文得需要想几秒，甚至需要翻译。
无详细说明
严重 BUG 修复
退货退款时间记录
虽然知道是修复严重 BUG，但是 BUG 是什么功能，为什么是严重 BUG 并不知道。而第二种虽然没多大毛病，但改成“补充遗漏退货退款完成时间”会更好些。
多个功能混在一起提交
修改 xxx
添加 xxx
去除 xxx
不建议这样子提交，但是后面回顾代码的时候区分不出每个项对应的内容。不要怕提交条数多，如果需要审阅代码就知道分开提交的好处了。
无意义的说明
修复 xxx 文件
提交记录里会记录当次提交的所有文件，没有说明的意义。
使用 GitHub issues 的方式提交
fix issues #894
这种提交是模仿 GitHub 上的提交方式，它会自动关联上指定的 issues，对直接在 GitHub 上审阅代码时很好用。但是对于完全独立的代码仓库来说，会不知道具体的问题是什么。可以保留这个方式写在说明第二行即可。gogs 也有类似的功能。但对于禅道，这种没有关联的来说，完全没有必要记录上去。
总结
对提交进行分类
统一提交格式
过段时间回来查看提交记录还能看明白提交说明，那就代表说明表述上没有问题
feat: xxx 功能
详细说明：
fix: xxx 功能的 xxx 问题
详细说明：
关联 issues：#123
del: xxx 功能 [的 xxx 方法]
详细说明：
adjust: xxx 功能 [的 xxx]
详细说明：
[] 为可选项