如何让你的git log简洁明了

2,194 阅读5分钟

什么是好的git log

好的git log需要有以下三个特点:

  • 简短
  • 直白
  • 统一

首先,对于commit log而言,大部分人根本不想在每一次提交中都看到你对需求背景或技术方案的长篇大论,所有这些背景性质的描述只需要在pull request中写清楚,或是整理到文档中。即使很多人赞同commit log写的越长越好,但是绝大多数情况下,这些内容在一次pr中都是同质化的,除非你每次commit都需要记录大量的信息。总之,虽然git允许你在commit log中写小作文,但是并不能说明这样的规范适合大多数人,毕竟大多数人并没有那么多时间。

其次,git log需要写的直白。我相信很多人都写过类似fix buginit这样的注解,虽然这么写很方便,但是其他人根本无法通过提交记录来获取信息。git log顾名思义是git的日志,日志不仅是要给自己看,也要给别人看。git log中包含了整个项目的发展记录,可以让新人快速熟悉项目,如果git log无法描述出该次提交的信息,那么git log就失去了‘日志’的含义。

最后,也是最重要的一点,git log需要有统一的规范。一间屋子即使再干净,只要一乱,就不可能让人舒服。即使你的commit log写的再简洁直白,只要没有统一的规范,看起来也是杂乱无章的。反之,只要规范统一了,看起来也会很舒服,别人也会更有耐心去翻看日志。

如何写好commit log

如今commit log大致分为以下两种类型:

  1. 简易描述方式 es

最常见的log格式,这种方式的log统一使用动词开头,在一行之内对commit记录进行描述。更加规范的log会要求开头的动词只能从某几个词语里选择,比如Add/Update/Merge等。

  1. 标签方式 vue

这种方式需要对每次commit的操作使用tag进行分类,比如feat(新增功能)/fixed(修复缺陷)/docs(更新文档)/refactor(重构)等,可以使用tag: xxx的方式,也可以使用[tag] xxx的方式。

除此之外,还可以在tag后备注本次操作的范围,比如给user模块添加了一个功能,就可以使用feat(#user): xxx的方式。如果本次变更有关联的需求,可以在最后追加issue编号,对于更加规范化的commit,则是对于每一次commit log都需要在前面备注本次变更所关联的需求,就像这样: spark

这两种方式中,相对而言更推荐第二种标签方式。首先,这种写法更清晰明了。同时,这种方式可以方便地对log进行分类筛选。比如,要查看登陆模块的所有功能更新,只需要输入git log --grep="feat(#login)"即可。

如果团队一直以来都使用规范的开发流程,那么可以在每次commit log上追加issue编号,方便进行查看。

如何保持git log的整洁

有很多人抱怨过规范的git log太难了,当然,很多人一开始还能好好写log,到后来就开始放飞自我了,这也难免,主要有以下两个原因:

  • 自动生成的merge log破坏了原本统一的规范
  • 频繁变更需求,或是考虑不周到,导致出现了大量无意义的commit log

所以,接下来就要介绍git rebase这个神器,只要会用rebase,完全可以写一行代码提交一行,每次commit log写成“aaa”也没关系,因为git rebase厉害就厉害在可以将多条commit log整合成一条。

rebase意为“变基”,即变更基础点,比如存在A和B两条分支,使用git merge会创建一个新commit记录,形成一个‘Y’状的log列表;而git rebase则是将第二条分支插到第一条分支中,你甚至可以用git rebase做一些“骚操作”,比如让你的commit记录出现在master之前(请一定不要在正式项目中这么干!)。

总之,这里只讲一下git rebase最常见的用法,即合并多条log为一条,以及修改commit log。比如,我们这里有4条log记录: git log

其中每次commit的操作为在文件中追加一行,现在我们的项目里只有一个file文件,内容如下: file

然后,我们要做的就是使用git rebase将这3条添加记录合并为一条,首先输入git rebase -i HEAD~3,其中HEAD指向当前的commit,可以使用commit id进行替换,~3指包含当前commit的前三次提交,执行后可以看到这样的界面: rebase log

其中log前的单词表示对该次commit要做什么操作,p/pick指选择,即不做修改,r/reword指修改commit log,s/squash指将该次commit合并到上一次,这里将后两条的pick改为s rebase1 然后保存,会弹出这样一个界面: rebase2 接着修改注释,然后保存 image.png

这时候我们再来查看git log就会发现之前的记录已经被合并了: new git log

通过这样的方式,即使每次提交的commit log都不规范,只要在抽出时间对自己的log进行合并整理,也可以保持log的整洁