我想大家都有过这样的经历：

你正在开发一个项目，它使用 Git 进行版本控制。

你刚刚完成更改，并且想要快速更新分支。

因此，你打开了终端，并通过一些快速命令，使用所做的更改来更新远程分支。

git add .
git commit -m "added new feature"
git push

但是随后你进行了一些测试，发现你的代码中存在 bug。

不用担心，你可以快速找到解决方案，并再次提交以解决该问题。

git add .
git commit -m "fix bug"
git push

你重复此过程几次，现在最终得到一个 git commit 日志，如下所示：

git commit 日志

目前，这对你来说似乎还不错，毕竟，你目前正在处理该部分代码，即使提交的信息不能传达你更改的意图，你仍然可以轻松地解释进行了哪些处理。

问题

几个月过去了，现在，另一个开发人员正在回顾你所做的更改。

他们试图理解你所做更改的细节，但是由于你提交的消息不是描述性的，因此他们无法获取任何信息。

然后，他们尝试去查看每个提交的差异。但是，即使这样做了，他们仍然无法确定你在实现中选择的背后的思考过程。

因此他们可以使用 git blame 找出是谁进行了这些更改，并开始向你询问有关实现的问题。

但是，由于时间已经过去很久了，所以你不会记得太多。你通过提交进行检查，而你不再记得该项目中执行决策背后的逻辑。

最终，你在微信上向同事发送了悲伤的表情符号 😔，并告诉他们你不能提供除他们知道以外的更多信息。

编写良好的提交信息

希望以上情况已经让你明白了为什么编写良好的 git commit 消息很重要。

在团队开发中，我们必须使其他协作者能够轻松地理解我们做了什么工作。

理想情况下，良好的提交消息将被分为三部分：主题，正文和结尾。

主题

主题应该是简洁的一行，总结你所提交的更改。

下面例举一个很好的提交信息，例如“feature：查询项目应用率功能”。

一个错误的提交消息，例如“fix bug”，在其他人看到这条提交信息的时候就会不知所措。

正文

正文包含你要传达的信息，你可以在其中详细了解有关更改的信息。请注意，对于一些很小的提交，例如修正错字，你可能不需要正文，因为主题行应该足够有信息性。

在正文中，你应该深入了解正在进行的更改，并说明正在执行的操作的前因后果。

你可以解释为什么要进行这些更改，为什么要选择以这种特定方式实施更改以及可以帮助人们理解你的提交背后的思维过程的其他任何原因。

尽量不要重复比较代码中显而易见的事情，无需逐行解释你的更改，专注于覆盖更多高级细节，这些细节从阅读代码中可能并不明显。最终目标是围绕此更改为开发过程提供上下文，该更改主要涉及其原因和目标。

结尾

你可以在最后一行写有关提交有用的元数据，例如 JIRA 票号，作者名字和附加链接。

这有助于将与你的变更相关的重要信息连接在一起。

总结

还等什么？等着被同事暴揍吗？那还不赶紧开始遵循有关 Git 提交消息的最佳实践！