程序员如何通过插件规范 Git commit message 的提交?

Git 相信大家在日常的工作中经常会使用到,在我们完成一个需求开发或者 bug 修复的时候都会将变动的代码文件进行 commit 提交到远程。

那么问题来了,仔细看下你的提交记录,里面是不是有很多 testfixupdateadd 等等丝毫看不出任何含义的 commit message

commit message 的提交很多时候都只依赖开发人员的自我规范,而开发人员往往在需求紧急或者 bug 要及时修复的时候,根本不会花很多时间在写 git commit message 的信息。而且就算是写,每个人的风格也不一样,所以写出来的 message 也不完全相同。

这个时候我们就需要有一套规范了,现在业界比较常用的规范是的格式是这样的:type(scope):subject,下面我们详细来聊一下。

Type

type 代表的是提交内容的一种类型,每一种类型都代表着不同的含义,具体的类型取值和含义如下:

  1. feat:表示开发一个新的需求特性;
  2. fix:表示修复一个 bug
  3. docs:表示是针对文档的修改,并没有修改代码;
  4. style:格式修改,不影响代码功能;
  5. refactor:不是进行 featfix 的代码修改,重构功能;
  6. perf:提升性能的代码修改;
  7. test:添加测试代码或者修正已经存在的测试功能代码;
  8. build:修改会影响构建或者依赖的代码;
  9. ci:修改集成配置的文件或者脚本;
  10. chore:一些不够影响到源码和测试文件的修改;
  11. revert:针对之前的一个提交的 revert 修改;

对于我们来说在写一个 git commit 的时候,要搞清楚当前提交的内容的真正含义是什么,从而选择正确的类型。此外还要求我们对于代码的修改需要尽量细粒度,话句话说就是尽量将一个大的改动进行拆分,根据适当的情况进行 git 提交,避免一次性提交太多的改动。

Scope

scope 表示的当次 git 提交的内容影响的范围,这个范围比较宽泛,比如可以是 DAO 层,Controller 层,或者是具有特定功能的比如 utils 工具模块,权限模块,数据模块等等,只要能跟自己的项目挂上钩,表达出修改的范围就行,如果涉及到的范围比较多的话,可以用 * 表示,并不强制要求。

Subject

subject 部分是最重要的 git commit message 的部分,也就是我们经常要写提交信息的部分,这一部分通常会一个言简意赅的信息描述,需要写出我们改动代码的原因。

上面的 typescopesubject 三个部分是我们常用的部分,不过有些规范将 git 的提交规范定义为 HeaderBodyFooter 三个部分,而 typescopesubject 三个属于 Header 的部分。

扩展

Header 部分也就是上面提到的三个部分,是每个 git 提交的基础内容;Body 部分则是更加详细的描述信息,用于完整记录代码的修改地方和逻辑;Footer 部分则会将本次提交的内容与具体的需求或者缺陷相关联,比如对应的需求地址是什么,或者修复的 Bug 缺陷是什么等。

IDEA 插件

上面的内容不多,但是要记下来的还是很繁琐的,特别是有时候我们很难记住所有的 type 类型,好在 IDEA 现在有一个插件,就是用来规范 git 提交模板的。

IDEA 的插件市场中安装 git commit template,直接搜索安装,然后重启 IDEA 即可。

0-10

安装完成过后,在我们需求提交代码的时候,会出现这个按钮。

0-11

点击一下就可以看到下面这个页面,其中 short description 就是我们上面提到的 subject,而 Long description 代表的就是 Body 部分,而下面的 Breaking changesClosed issues 则代表的是 Footer 部分,在使用的过程中按需填入即可。

0-12

总结

有很多小伙伴就要问了,写那么详细有什么用?规范我们的提交记录,主要是为了能追溯代码历史,很多时候我们自己写的代码在时间长了以后都记不住,更不要说别人写的代码了,所以只能从流程和规范上面来帮助大家更好的记忆。

评论