共 1926 字，读完需 4 分钟。所有工程师都知道，代码是编写一次，修改很多次，然后阅读更多次，代码可读性的重要程度不言而喻，但是在项目演进过程中有个很重要的记录也是会读很多次的，那就是 Git 的提交日志，而提交日志里面信息量最大的应该是 commit message，本文灵感来自 Linux 作者 Linus Torvalds 在 GitHub 上对 commit mesage 的吐槽。

Git Log 之痛

在《The Art of Readable Code》这本经典书中，有个形象的比喻，衡量代码可读性的指标是阅读代码时每分钟的 WTF 次数，而在读 Git 提交历史的时候，不知道你有多少次爆粗口？不相信？你现在打开公司演进最快的项目，执行 git log，信息量过少甚至是误导的 commit message 非常常见，比如：

fix     => 这到底是 fix 什么？为什么 fix？怎么 fix 的？
update  => 更新了什么？是为了解决什么问题？
test    => 这个最让人崩溃，难道是为了测试？至于为了测试而去提交一次代码么？

说不定，你在这种 commit message 中也贡献了一份力量呢。

正视问题

我们先放下 Git 提交日志来看看典型的后端日志记录，如下面这则 access log：

remote_addr=[127.0.0.1] http_x_forward=[-] time=[19/Apr/2017:07:28:13 +0800] request=[GET /admin/edu/exam_scores/index/225 HTTP/1.1] status=[200] byte=[15745] elapsed=[0.309] refer=[http://stu.youcaiedu.com/admin/edu/contests] body=[-] ua=[Mozilla/5.0 （Macintosh; Intel Mac OS X 10_12_4） AppleWebKit/537.36 （KHTML, like Gecko） Chrome/57.0.2987.133 Safari/537.36] cookie=[JSESSIONID=aaaXlJyT6Ju-K-FbLuWPv; pgv_pvi=7986424832; pgv_si=s905561088; easycms=a16pbumhusksq3vpcogcv2n715; toolbarDisplay=hide; _ga=GA1.2.1604145244.1486802034] gzip=[7.71]

好的 access log 包含了哪些要素呢？

用户请求的时间（time）；
用户请求的地址（request）、从何而来（refer）；
用户来源（remote_addr）；
服务端响应（status, byte, elapsed）；
...

回忆下小学的知识，如何准确的描述一次事件？对，就是 5W1H 法则，具体说就是谁（who）在什么时候（when）、什么地点（where）因为什么（why）而做了什么事情（what），他是怎么做的（how），access log 是典型的事件日志，所以 access log 的记录完全可以参照 5W1H 方法去记录，你后来翻看的时候也不会错过细节。

回到正题，Git Log 本质上不也是事件日志么？必然是线上出了问题、产品提出了需求、工程师自己做了重构或技术改进才会导致它的变迁。如果没有详尽记录每次变迁的细节，代码 Review 的人怎么知道你做了什么？上线后遇到问题怎么去追溯？新人接手代码怎么去理解？

解决问题

因为 Git 的特殊性，Git 内核已经能把 5W1H 里面的 who、when 作为 commit 元信息记录下来，而研发活动的 where 明显是不需要记录的，真正需要工程师关注的是 what、why、how，这 3 项重要信息的载体就是 commit message。相信读到这里，你已经明白我想说什么了。

下面提出一种可以帮你写出高可读 commit message 的实践方法，这个方法并非原创，最早的实践来自于这篇文章。简单来说就是要在 commit message 中记录本次提交的 what、why、how，那么怎么把这个想法集成到你的开发工作流里面呢？可以参考下面的步骤来完成：

1. 设置 .gitmessage 模板

这是 Git 内置就支持的，你可以为每次提交的 commit message 设置一个模板，每次提交的时候都能促使你遵循这个思考的模式去编写 commit message，比如下面是我的模板，存放在 ~/.gitmessage：

What: 简短的描述干了什么

Why:

* 我为什么要这么做？

How:

* 我是怎么做的？这么做会有什么副作用？

2. 让模板生效

在全局 Git 配置 ~/.gitconfig 中添加如下配置：

[commit]
  template = ~/.gitmessage

3. 拥抱新模板

配置好模板之后，你要放弃在提交时直接指定 commit message 的习惯做法，即下面这种提交方式：

git commit -m "<commit message here>"

因为这种提交方式是不会弹出模板来让你填写的，你提交的命令应该改成：

git commit

具体的操作过程见下面的动图：

如同阿米尔汗在给他女儿做摔跤战术指导时说的话：拿五分很难，但不是没有可能。习惯的养成定不容易，但是是可行的，如果你认识到这点，离习惯养成已经很近了。

4. 给用 Vim 的同学

为了更好的 commit message 阅读者体验，可能你需要考虑给 commit message 里面的内容自动换行，让内容控制在轻松能看到的宽度之内，使用 Vim 的同学可以在你的 ~/.vimrc 里面增加下面的配置：

autocmd Filetype gitcommit setlocal spell textwidth=80

5. 最重要的是内容

写出高可读的 commit message 需要你对每次提交的改动做认真深入的思考，认真回答上面提到的几个问题：

What: 简短的描述这次的改动
Why：为什么修改？就是要说明这次改动的必要性，可以是需求来源，任务卡的链接，或者其他相关的资料；
How: 做了什么修改？需要说明的是使用了什么方法（比如数据结构、算法）来解决了哪个问题；

此外，还有个非常重要的点就是本次修改的副作用可能有什么，因为工程就是不断在做权衡，本次修改为以后留下了什么坑？还需要什么工作？都可以记录在 commit message 中。

从本质上来说，上面只是你思考问题的框架和记录内容的形式，真正重要的是你要仔细思考的那几个问题，因为一定程度上，commit message 就是文档，活的文档，记录了仓库的所有变迁。

总结

怎么让你的代码可以追溯也是优秀工程师必备的素质，相信读到这里，你对如何写出高可读的 commit message 的原因、好处、方法有了清晰的认识，纸上得来终觉浅，绝知此事要躬行，接下来你就需要把这种方法运用到实际工作中，相信我，你的同事发现之后会开始感激你、效仿你。

One More Thing

本文作者王仕军，商业转载请联系作者获得授权，非商业转载请注明出处。如果你觉得本文对你有帮助，请点赞！如果对文中的内容有任何疑问，欢迎留言讨论。想知道我接下来会写些什么？欢迎订阅我的掘金专栏或知乎专栏：《前端周刊：让你在前端领域跟上时代的脚步》。