有意提交

有一天，我在 GitHub 存储库中浏览时看到了这条提交消息：

并不是说我需要知道这个人当时提交了什么，但我忍不住想，如果有人需要了解这个项目，这个提交信息将是多么无用。

我也犯过提交信息不够清晰的错误——我相信大家都有过类似的经历。如果你想看一些真正搞笑的提交信息，可以访问whatthecommit.com。

在我的工作中，我们开始使用基于传统提交规范的Commitizen。虽然花了一点时间来适应，但几天后，我就看到了它为代码库带来的价值。

分解提交大小

因为它将提交分成几类，所以它强制您只将相关文件添加到一个类别中。

告别一次性编辑 30 个文件并提交的烦恼。我的意思是，你仍然可以这样做，但每次在测试变更中添加功能变更时，你都会感到一丝愧疚。

使用该工具几天后，我开始思考工作中哪些地方可以提交，并力求使我的提交信息最有意义。例如，当开发一个包含重构工作的功能时，我会尝试先进行重构，提交重构，然后再开始开发新功能。浏览文件时回顾提交信息，了解所做的更改类型，这对于细化细节以及了解每次提交的预期结果非常有帮助。

更多描述性消息

虽然网上其他人可能已经把提交信息拆分成了主题和正文，但我没有。现在我意识到，正文中更长的描述对于描述你所做的更改的细微差别非常有帮助。即使只是在提交拉取请求之前过一遍，它也能帮助你更彻底地理解你为什么这么做——前提是你真的添加了详尽的描述。

在我的工作中，我们更进一步创建了一个自定义命令行工具，该工具可以在 Github 上为您发出拉取请求，拉取请求描述就是您的 git 提交列表。起初，我担心这还不够。100 个字符的提交消息怎么能告诉你关于代码更改的所有信息呢？但后来，我灵光一闪：提交应该已经告诉你关于代码更改的所有信息了。只是我的提交做得不够好。一旦我开始按提交类别细分并提供更好的提交消息（主要是通过更长的描述），我的拉取请求就回到了以前的水平，那时我会自己编写描述，提交消息也不那么标准。

我鼓励每个人都安装 Commitizen 并试用几天。我相信，当你将来回顾自己的代码并思考“我到底在想什么？”时，它会让你更加快乐。