编写同事会喜欢的 Git 提交消息

Git 提交信息是我们与未来的自己沟通的方式。它能帮助你理解为什么某一行代码会被添加到代码库中。因此，了解如何编写优秀的 Git 提交信息至关重要。

我们都有过这样的经历：“ Git 太让人困惑了”、“为什么我不能直接推送到主分支？ ”、 “根本没人会读到这条信息”。这些想法很正常，大多数学过 Git 的人可能都有过类似的感受。你可能只有在使用一个已经存在多年的代码库，或者回到你的旧项目时，才会真正欣赏好的提交信息。

在本文中，我将向您展示如何编写您和您的同事会喜欢的 Git 提交消息。

为什么 Git 提交信息很重要

您是否打开过旧项目并用 查看过提交信息git log？如果没有，我建议您现在就检查一下。如果它们没有“修复样式”或“添加端点”，那就太棒了！如果您和我们一样，请继续阅读😄

或者，你加入了一家公司，它的代码库已经存在了好几年。你正在尝试理解为什么添加了某段代码。修改这段代码会破坏任何功能吗？在这种情况下，一条好的提交信息就显得弥足珍贵。

简而言之，通过编写良好的 Git 提交信息，您可以为自己和同事的未来做好准备。作为开发人员，我们阅读的代码比编写的代码要多得多。

阅读与编写代码

鲍勃叔叔（罗伯特·C·马丁——《代码整洁之道》等热门编程书籍的作者）说

事实上，阅读与写作所花费的时间比例远远超过 10:1。我们不断地阅读旧代码，以此作为编写新代码的努力的一部分。……[因此]让代码易于阅读，也更容易编写。(参考)

有时，为了理解代码，你还需要阅读提交信息。希望你现在明白，写一条好的提交信息是值得的！

如何编写良好的 Git 提交信息

既然您已经确信提交消息很重要，那么让我们看看如何以您的同事喜欢的方式编写它们！

提交消息由两部分组成：主题行和正文。以下是来自比特币仓库的一个例子。

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

   Simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.
   ...

第一行是主题，换行符之后的内容是正文。

关注“为什么”

这是最重要的规则，也是最常见的错误。提交信息应该解释代码添加的原因，而不是添加了什么。要了解添加的内容，我只需阅读代码即可。但要理解原因，我只能猜测。

即使我是代码的作者，我最终也会忘记为什么。

在主题行中使用祈使语气

命令式的意思是“用于命令或要求执行某项操作”。这是 Git 默认使用的语气，你也应该如此。

例如，该git revert命令将为您创建一个所谓的“还原提交”。此提交的主题行将采用祈使语气：“还原‘将字段添加到架构’”。

你可以把它想象成你正在告诉系统/应用程序/等等如何操作。一开始可能会有点别扭，但你会慢慢习惯的。

注意：您可以按照自己喜欢的任何心情来编写提交主体。

将主题行长度限制为 50 个字符

你在 GitHub 上见过以 结尾的提交信息...吗？这是因为如果主题行超过 72 个字符，GitHub 就会将其截断。主题行的剩余部分会移至提交正文。

GitHub 建议提交长度不超过 50 个字符。这个限制是为了提高提交的可读性。这样你就必须以简洁易懂的方式解释你的代码更改。

如果您无法用 50 个字符解释代码变更，则可能是因为一次提交的变更过多。如果是这种情况，您应该将提交拆分成多个提交。

结论

这是编写 Git 提交信息时要遵循的三个最重要的规则。如果你遵循这些规则，你的同事就能很快理解这次提交的含义。

总结一下：

• 关注“为什么”
• 在主题行中使用祈使语气
• 将主题行长度限制为 50 个字符

要了解更多 git commit 最佳实践，请查看这篇精彩的博客文章。

通过Twitter、LinkedIn或GitHub与我联系