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

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

那么问题来了，仔细看下你的提交记录，里面是不是有很多 test ，fix，update，add 等等丝毫看不出任何含义的 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：不是进行 feat 和 fix 的代码修改，重构功能；
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 的部分，也就是我们经常要写提交信息的部分，这一部分通常会一个言简意赅的信息描述，需要写出我们改动代码的原因。

上面的 type，scope，subject 三个部分是我们常用的部分，不过有些规范将 git 的提交规范定义为 Header，Body 和 Footer 三个部分，而 type，scope，subject 三个属于 Header 的部分。

扩展

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

IDEA 插件

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

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

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

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

总结

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