如何写好Git commit的信息

Git commit是代码提交时必经之路，commit虽然没有具体的规范，但也不能太过于随意，不然当你回头浏览git仓库的日志时，也可能会一脸懵逼（小编就曾经被点名，都怪小编当年过于放荡不羁 ￣□￣｜｜ ）

下面小编总结了一些Tips：

1、one thing one commit

在提交commit的时候尽量保证这个commit只做一件事情，比如实现某个功能或者修改了配置文件。

这样会有几个好处：

• 易读：阅读整个项目代码的时候有时候整个项目通读并不是一个好的方法。我们可以通过 issue 或者 commit 来一点一点分解整个 repo。如果一个 commit 只聚焦在一个点上，那么代码看起来也会比较舒服，顺着 commit 读下来就是当初的开发过程了。
• cherry-pick：cherry-pick 是 git 中的一个非常有用的命令，可以将 commit 从一个分支“拷贝”到另一个分支。如果我的 commit 划分都很清楚，那么 cherry-pick 就会比较轻松。但是如果我的一个 commit 即实现了功能A，又实现了功能B，而我只想要功能A，这就很尴尬了。
• code review : review 过别人代码的人都知道如果 commit 乱七八糟那将有多么痛苦。如果commit msg写得清晰就可以方便代码的阅读。

2、规范

# 50-character subject line
#
# 72-character wrapped longer description. This should answer:
#
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# Include a link to the ticket, if any.

文章《5 Useful Tips For A Better Commit Message》中是这样规定：

1. 第一行不超过50个字符；

2. 第二行空一行

3. 第三行开始是描述信息，每行长度不超过 72 个字符，超过了自己换行；

4. 描述信息主要说明：

   （1）这个改动为什么是必要的？

   （2）这个改动解决了什么问题？

   （3）会影响到哪些其他的代码？

5. 最后最好有一个相应的ticket的链接

​当Commit主题不超过50个字符，然后空一行，这样显示的下面的部分都会折叠起来，类似下面的样子。我们使用命令 git log --oneline的时候就只显示第一行。正文部分不超过 72 个字符，也主要是为了阅读方便。关于最后的一个 ticket 的说明。我们开发之前需要将所有的功能进行拆解，然后开发过程中需要通过一些工具来 track ，每个小功能就是一个 ticket。有些公司使用 jira，有些公司使用 wiki。以使用 jira 为例，前面把功能拆解之后分到每个人手上。这样我们进行提交的时候附上对于的 ticket 链接或者 ticket 号，之后再回溯的时候就会非常方便了。或者也可以给 jira 开发插件，通过抓取 git commit 信息进行分析就能将相应的改动代码直接展示在 jira 上了。这么做的好处不言而喻，需求-功能-开发-代码，整个都被串起来了，不管是对于新人了解系统还是5年或者10年之后回溯都是非常有帮助的。