程序员如何通过插件规范 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部分，在使用的过程中按需填入即可。

图片

总结

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