那么问题来了，仔细看下你的提交记录，里面是不是有很多 test ，fix，update，add 等等丝毫看不出任何含义的 commit message。
commit message 的提交很多时候都只依赖开发人员的自我规范，而开发人员往往在需求紧急或者 bug 要及时修复的时候，根本不会花很多时间在写 git commit message 的信息。而且就算是写，每个人的风格也不一样，所以写出来的 message 也不完全相同。
这个时候我们就需要有一套规范了，现在业界比较常用的规范是的格式是这样的：type(scope):subject，下面我们详细来聊一下。
Type
type 代表的是提交内容的一种类型，每一种类型都代表着不同的含义，具体的类型取值和含义如下：
- feat：表示开发一个新的需求特性；
- fix：表示修复一个 bug；
- docs：表示是针对文档的修改，并没有修改代码；
- style：格式修改，不影响代码功能；
- refactor：不是进行 feat 和 fix 的代码修改，重构功能；
- perf：提升性能的代码修改；
- test：添加测试代码或者修正已经存在的测试功能代码；
- build：修改会影响构建或者依赖的代码；
- ci：修改集成配置的文件或者脚本；
- chore：一些不够影响到源码和测试文件的修改；
- 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 部分，在使用的过程中按需填入即可。
图片
总结
有很多小伙伴就要问了，写那么详细有什么用？规范我们的提交记录，主要是为了能追溯代码历史，很多时候我们自己写的代码在时间长了以后都记不住，更不要说别人写的代码了，所以只能从流程和规范上面来帮助大家更好的记忆。
