![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsICMyYTMvw1dvwlMvwlM3VWaWV2Zh1Wa-cmbw5CbphmchRWM4NHbvwVN5QTO0AjNtUGall3LcVmdhNXLwRHdo9CXt92YucWbpRWdvx2Yx5yazF2Lc9CX6MHc0RHaiojIsJye.png)
With Git, I think it was a lot about coming at a problem with fresh eyes, and really trying to think about the issues, and spending a fair amount of time thinking about what the real problems were and what I wanted the design to be. —— Linus Benedict Torvalds
我曾经经历过一段从 SVN 切换到 GIT 的过渡时期。
从最初的彷惶(为什么要切换到 GIT)、中间的坚持(说服并帮助其他开发同学),以及最后的成功(所有开发同学都能熟练运用)。
然后,往前回顾。支撑起无数次代码变更与重要里程碑发布的 GIT。它是最先进的版本管理系统!真香!
然而,GIT 本身虽好。如果使用者不善于使用,那么还是会生米煮成一锅粥。
混乱的 Commit Message
举个例子:翻了一下自己的 Github 上的 Commit Message 历史记录。
图 A - 反面教材一
图 B - 反面教材二
图 C - 反面教材三
可以发现,从 2019 年(或许更早)开始 Commit Message 记录完全是一团糟。以至于,现在我已经看不懂当时为什么要修改、为什么要提交。
同理,假如从一个产品级代码库、或者多个产品级共用的代码库,都是如此的话。那么,整个代码库的可维护性已经降到了最低,只是目前还没爆裂而已。
总结下存在的问题点:
- Commit Message 格式不统一,甚至是毫无格式可言;
- Commit Message 没有明确的问题,说明修改了什么内容、为什么要修改;
规范的 Commit Message
反面教材之后,当然是一个正规的格式:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
复制
- type - 更改的类型。例如:feat、fix、perf、docs、chore、style、refactor、test 等。
- feat:新功能(feature)
- fix:修补 bug(需要提供 bug 编号)
- perf:提高性能
- docs:文档(documentation)
- chore:构建过程或辅助工具的变动
- style:格式(不影响代码运行的变动)
- refactor:重构(即不是新增功能,也不是修改bug的代码变动)
- test:增加测试
- scope - 更改的作用域。例如:client、service、common 等。
- subject - 更改的主题。使用现在时的命令性语气,不要大写第一个字母,文字末尾不加句号。
- body - 对变更的描述,改变的动机,并将其与以前的行为进行对比。
- footer - 引用此提交关闭的 GitHub 问题的地方。
总结
“不以规矩,不能成方圆”。
软件开发是一个需要团队协作的工作,所以一个良好的规则可以让开发工作变得更加得心应手。
让我们一起每天进步一点点。
感谢各位小伙伴的阅读,这里是一个技术人的学习与分享。