git 提交记录回顾总结

2024年3月31日 204次阅读 来源: jani

说明

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

示例

只有操作类型

  • fix
  • add

上面这两个可以知道是修复功能和添加功能，但是需要看代码才能知道修复的是什么，添加的是什么。

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

  • fix refund

英文不好的人可能看到英文得需要想几秒，甚至需要翻译。

无详细说明

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

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

多个功能混在一起提交

  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]
详细说明：

[] 为可选项
    原文作者：jani
    原文地址: https://segmentfault.com/a/1190000018572370
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞