作者：程序员小跃
slogan：当你的才华还无法撑起你的野心时，那应该静下心来好好学习
作为一名优秀的程序员，作为一个优秀的团队，作为一家优秀的软件公司，不可能不用版本控制工具。
那么请问，你觉得你填写 commit 信息之后，过一周、一个月、一季度甚至是一年之后，你还能看得懂当初做过的提交吗？当一个新同事来修改bug，请教你为什么会这么修复的时候，你脑海里是否还能浮现当初深思的场景呢？
我在前公司工作那几年，代码提交信息都是有严格要求，有统一的格式。在提交代码之前，会通过另一位同事的协作（即 code review），审查你修复的大致内容，然后填上相应的修改信息才能入库。
这样的好处是什么呢？就是能在下一个bug出来之后，很好地往回追溯，以确认是你修改引入，还是考虑不全，还是修改无效等。
这样能更好地提高你写代码的能力，当你敲下键盘的时候，能考虑更多，能想得更多，更严谨。而且，还能在复盘的时候，有依可循，你觉得呢？
在那里3年的时光，让我养成了提交详细信息的习惯。所以，当今天看到这篇外文，我饶有兴趣地点进去阅读，想知道歪果仁是如何做好一个优秀的 commit 信息，读完之后，相信你也能收获更多。
先来看看我做的原文翻译：
停止编写糟糕的提交信息
开始遵循Git提交信息的最佳实践
作者：Devin Soni
时间：1月8日
我们都见过…
你正在开发一个项目，用到了Git版本控制工具。
你刚完成了一个代码修改，希望快速地更新到你所在的分支。
这时候，你打开终端，快速敲了几个命令，就可以把你更新的信息更新到远程分支。
用到的命令如下：
gid add
git commit -m "added new feature"
git push
但是，当你做了一些测试，结果发现你的代码中还存在一个bug。不用担心–你很快就解决它，并且又做了一次提交去修复这个bug。
git add
git commit -m "fix bug"
git push
当你重复这个过程好几次，就会得到一个提交日志，如下所示：
此时，这对你来说似乎挺好的。
毕竟，你持续在做，而且你可以轻松地解释你在做什么–即使信息没有很清楚地传达。
这个问题
几个月过去了，现在，另一个开发人员正在会看你所做的更改。
他们试图去裂解更改的高级细节，但是由于提交的描述信息有限，他们无法收集任何信息。
然后，他们去阅读每个提交的差异信息。然而，即使这样做了，他们仍然不能识别出你在实现中当时做的思考过程。
现在，由于软件工程是一个协作过程，而且存在git blame操作，所以他们会找出是谁做了修改，并开始向你咨询关于你的实现问题。
然后，因为时间过去很久，你也记不了多少信息。你通过提交记录查看，但是也还是记不得在项目中实现这个修复背后的思想逻辑。
你给你同事发了一个很遗憾的表情，很遗憾的告诉他们，除了他们看到的提交信息，你也不能提供更多有效的信息了。
编写良好的提交信息
希望上面讲的实际情况，能很好的说明为什么编写良好的、信息丰富的git提交信息很重要。
在一个像软件工程一样需要协作的领域，我们必须使合作者很容易地在我们的工作中快速获取到相应的上下文联想信息。
在理想情况下，一个优秀的提交信息应该由三部分组成–主题、正文和结束行。
主题
主题应该单独成行，写上你提交记录的概要信息。
他应该是祈使句，以大写字母开头，不用句号结尾，字数不能超过50个字符。（这是英文要求，我们中文提交可以做参考，甚至也用英文来写提交信息）
一个好的主题可以完成**This commit will…**这样的理解（同理，中文就是：这个提交将…：）
一个优秀的提交信息，比如“add new neural netword model to back-end”,(中文：向后端添加新的神经网络模型)，这样就很好地完成了这个句子
一个糟糕的提交信息，例如“fix bug”（你中招了吗？）这个就不能很好的完成句子，从而产生“This commit will fix bug”(这个提交将修复bug)，这样尴尬的字面理解。
内容
正文包含消息的主要内容，你可以在其中详细描述有关更改的信息。也请注意，对弈一些非常小的提交，比如修复一个输入错误，你可能不需要正文，因为主题已经提供了足够的信息。
在正文中，你应该更详细地介绍你所做的修改，并解释你所做修改的上下文内容。
你可以解释为什么要进行这些修改，为什么要选择以这种方式实现这些修改，以及其他任何能帮助别人理解你思考过程的内容。
尽量不要重复那些从diff中的代码修改中可以很明显理解的内容，没有必要逐行解释你的修改。更多的关注更高层次的细节，这些细节可能在阅读代码是并不明显。我们的最终目的是为围绕这个变更的开发过程提供上下文信息，主要是关注其动机和目标。
结束行
最后，结束行是提交信息的最后一行。
这里可以放置关于提交的有用的元数据，比如 JIRA单号、GitHub issue号，作者姓名，以及其他链接等。这有助于将你修改相关的重要信息链接在一起。（我个人的习惯，加上日期）。
结语
很高兴你和我一起学习完了，请问此时的你什么感想？这里遇到的问题，你是否曾经遇到过。
如果是，说明你还有很大的提升空间，你修改bug，回溯问题的效率还能更高；如果你已经在做了，那么恭喜你，请继续保持。
作为程序员，基本上每天都在用版本控制工具，编写良好的 commit 日志是对自己负责，也是对项目负责，能让你事半功倍，实践起来！
