资讯专栏INFORMATION COLUMN

使用 "5W1H" 写出高可读的 Git Commit Message

DevYK / 2164人阅读

摘要:共字,读完需分钟。下面提出一种可以帮你写出高可读的实践方法,这个方法并非原创,最早的实践来自于这篇文章。本文作者王仕军,商业转载请联系作者获得授权,非商业转载请注明出处。

共 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 ""

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

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

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

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/24927.html

相关文章

  • 前端自动化部署-.gitlab-ci.yml配置

    一、前言该过程中用到的技术栈git gitlab shell需要提前准备的内容一个项目myweb本机安装Git一个Gitlab仓库docker私有仓库gitlab runner(Gitlab-runner)公司的代码一般都保存在私有化部署的Gitlab,要使用Gitlab的CI/CD,需要Gitlab版本>8.0.0CI/CD虽然不难,但配置过程中有很多坑,而且有些要了解的概念也比较多,可以...

    社区管理员 评论0 收藏0
  • Docker安装及错误解决方案

    1 关闭selinux[dddd@v069208183.sqa.zmf/home/admin/] $sudosetenforce0 setenforce:SELinuxisdisabled [dddd@v069208183.sqa.zmf/home/admin/] $sudosed-i'/^SELINUX=/c\SELINUX=disabled'/etc/selinux/confi...

    3119555200 评论0 收藏0
  • 从0开始构建自己的前端知识体系-不要对"=="说不

    摘要:为了避免某些场景下的意外,甚至推崇直接使用来代替。使用了运算符的一些规则,发生了类型转换。按照以下规则转换被传递参数直接返回直接返回直接返回直接返回直接返回返回一个对象的默认值。 前言 类型转换在各个语言中都存在,而在 JavaScript 中由于缺乏对其的了解而不慎在使用中经常造成bug被人诟病。为了避免某些场景下的意外,甚至推崇直接使用 Strict Equality( === )...

    tianyu 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<