请中止编写糟糕的提交消息！

我想你们都有过这样的经历：

你正在开发一个项目，它使用 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 提交消息的最佳实践！

完

●看完这篇还不会用Git，那我就哭了！
●最大的 String 字符长度是多少？
●Nginx 了解一下？
●你真的了解 volatile 关键字吗？
●Java中Set集合是如何实现添加元素保证不重复的？
●一篇文章带你了解 ZooKeeper 架构

武培轩有帮助？在看，转发走一波喜欢做者