git 提交记录回顾总结

说明

年前我须要写公司的年度工做总结，因此把项目里的提交日志拉出来查看，其中有几类提交是无效的也是没有意义的，整理起来十分蛋疼，因此记录下来。翻译

示例

只有操做类型

• fix
• add

上面这两个能够知道是修复功能和添加功能，可是须要看代码才能知道修复的是什么，添加的是什么。日志

提交说明使用外文进行说明

• fix refund

英文很差的人可能看到英文得须要想几秒，甚至须要翻译。code

无详细说明

• 严重BUG修复
• 退货退款时间记录

虽然知道是修复严重 BUG，可是 BUG 是什么功能，为何是严重 BUG 并不知道。而第二种虽然没多大毛病，但改为 “补充遗漏退货退款完成时间” 会更好些。it

多个功能混在一块儿提交

1. 修改xxx
2. 添加xxx
3. 去除xxx

不建议这样子提交，可是后面回顾代码的时候区分不出每一个项对应的内容。不要怕提交条数多，若是须要审阅代码就知道分开提交的好处了。方法

无心义的说明

• 修复 xxx 文件

提交记录里会记录当次提交的全部文件，没有说明的意义。总结

使用 GitHub issues 的方式提交

• fix issues #894

这种提交是模仿 GitHub 上的提交方式，它会自动关联上指定的 issues，对直接在 GitHub 上审阅代码时很好用。可是对于彻底独立的代码仓库来讲，会不知道具体的问题是什么。能够保留这个方式写在说明第二行便可。gogs 也有相似的功能。但对于禅道，这种没有关联的来讲，彻底没有必要记录上去。项目

总结

1. 对提交进行分类
2. 统一提交格式
3. 过段时间回来查看提交记录还能看明白提交说明，那就表明说明表述上没有问题

feat: xxx 功能
详细说明：

fix: xxx 功能的 xxx 问题
详细说明：
关联issues：#123

del: xxx 功能[的 xxx 方法]
详细说明：

adjust: xxx 功能[的 xxx]
详细说明：

[] 为可选项