5

共 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

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


wangshijun
2.3k 声望423 粉丝

资深前端工程师、架构师、布道师、麦子学院金牌讲师、前端周刊编辑