【译】求你不要再写没用的提交信息了

开始尝试优化你的 Git 提交信息吧git

咱们都看到过的

你在一个项目中使用 Git 做为版本控制。web

当你作完了一次修改以后,你想要尽快更新你的分支。微信

因此你打开了终端,输入了下面这些命令,完成了一次远端分支的更新。编辑器

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

而后你作了一些自测,发现了一个新鲜的 bug。问题不大,你很轻松的就解决掉了这个 bug,如今你须要把新的代码再次提交到远程分支,因而你很熟练的使用起 Git 命令。flex

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

你几乎天天都在重复作着这样的事情,当你打开 Git log 时,你会发现它长成了这个样子。优化

git log

到目前为止,一切看上去对你来讲都还不错。毕竟你很熟悉你的代码仓库,即便不须要提交信息的提醒,你也知道每次修改都是在进行了哪些操做。spa

存在的问题

过了几个月,其余的开发者浏览了你过去的修改,他们想要尝试更深刻的理解关于你所作的修改的一些细节问题,可是你的提交信息并不具有描述性,他们也就没法从中获取任何有用的信息。.net

无奈之下,他们只能挨个查看每次提交的不一样,然而即便这么作了,他们也仍是不能很明确的知道你在开发过程当中一些选择的理由和你的一些思考。版本控制

因为软件开发是一个协做的过程当中,因此人们老是会使用 git blame 操做来查看是谁对代码作了修改,而且会问你一些关于代码的问题。可是距离你写这段代码已通过去很长时间了,你的印象也比较模糊。当你查看你的提交时,你发现本身很难说出当时为何要这么写,以及其中的一些逻辑细节。code

你给同事发送了一个悲伤的表情,而且告诉他们,你没有办法给他们提供更多的信息。

书写优秀的提交信息

但愿经过上面的故事,你已经知道了为何要编写良好的、信息丰富的 Git 提交信息:

在软件工程这样须要协做的领域中,它能够帮助咱们快速理解上下文。理想状况下,Git 提交信息须要由三部分组成:主题、正文和结语。

主题

主题须要是一句话来归纳你提交内容所涉及的修改。它须要是祈使时态,以大写字母开头,结尾没有句号,而且最好小于50个字。

一个好的主题格式应该是像“This commit will …”这样的。好的提交信息也应该是一个比较完整的句子。“add new neural network model to back-end”。

而很差的提交信息就不是一个完整描述的句子,好比最多见的“fix bug”。

正文

正文须要包含你要传达的信息,让其余人在其中可以了解更多关于此次修改的细节。对于一些比较修改的修改,好比改动了一个变量类型,你可能不须要写正文,主题就足够描述此次修改的内容了。

在正文中,你应该更详细的描述此次修改中的一些细节问题,而且解释你所作的事情的来龙去脉。

你能够解释为何要作出这个修改,为何用这种特殊的方式来实现,或者其余你以为可以帮助其余人理解你的修改过程的信息。

注意不要重复描述代码中显而易见的逻辑,正文也不是让你一行一行的解释代码,你们更加关注的是代码中不容易看出来的更深层的一些细节问题。咱们的最终目标是为此次的修改提供有效的上下文信息,即更改主要的动机和目标。

结束语

最后,结束语应该出如今你的提交信息的最后一行。

你能够在这里提供一些关于这次修改的元数据,好比 JIRA 号,GitHub issue 号,合做者姓名,和附加信息的连接。

这有助于将你的修改的相关重要信息连接在一块儿。

原文连接

https://medium.com/better-programming/stop-writing-bad-commit-messages-8df79517177d

可点击阅读原文查看

往期精彩回顾
Elasticsearch源码解析:环境搭建
Elasticsearch从入门到放弃:再聊搜索
Elasticsearch从入门到放弃:分词器初印象


本文分享自微信公众号 - 代码洁癖患者(Jackeyzhe2018)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。