Commit Message 杂谈：劣与优

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 问题的地方。

总结

“不以规矩，不能成方圆”。

软件开发是一个需要团队协作的工作，所以一个良好的规则可以让开发工作变得更加得心应手。

让我们一起每天进步一点点。

感谢各位小伙伴的阅读，这里是一个技术人的学习与分享。