自己的git commit 提交规范

自己使用git进行管理项目代码时候，往往要通过 git commit  -m  "this is a test commit "命令来提交每次提交的信息来表明此次提交做了哪些的修改。

commit message 的好处

1. 提供更多的历史信息，方便快速浏览。
2. 可以过滤某些commit（比如文档改动），便于快速查找信息。
3. 可以直接从commit生成Change log。

但是有个问题，这个提交信息原则是都是每次都要填的（不填不让提交），但也仅此而已，git不会限制你填的内容，格式，所以显而易见会出现各种各样，五花八门，只有想不到没有写不出的message。

所以对提交messgae添加更多的限制是很有必要的。

严格模式下的 commit message 格式

header 
  <type>(<scope>): <subject>
<空一行>
body
  Body部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。
<空一行>
footer

type：包含此次提交的类型

1. feat：新功能（feature）
2. fix：修补bug
3. docs：文档（documentation）
4. style： 格式（不影响代码运行的变动）
5. refactor：重构（即不是新增功能，也不是修改bug的代码变动）
6. test：增加测试
7. chore：构建过程或辅助工具的变动

scope：包含此次提交影像的范围

     比如数据层、控制层、视图层等等或者模块A，模块B，或者生产环境，配置文件等等，视项目不同而不同。

subject： 此次提交的简短描述

1. 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
2. 第一个字母小写
3. 结尾不加句号（.）

但是对于很多项目而言，每个都用上这种严格的提交格式，或许有点麻烦，定义一个自己可以遵守的提交标准或许更加符合实际要求、不用强制校验，自己自觉遵守。

格式：type(scope) :description   表示：提交类型（范围）：提交简短描述

type：

#主要使用type

1. fix: 修复bug
2. add: 新功能

#代码修改优化type

1. refactor：重构（即不是新增功能，也不是修改bug的代码变动）
2. style : 代码格式改变，不影响代码含义的改动，例如去掉空格、改变缩进、增删分号；
3. test: 增加测试代码

#版本控制type

1. revert: 撤销上一次的commit
2. merge：合并分支

#开发环境type

1. build: 构建工具或构建过程等的变动，如：gulp 换成了 webpack，webpack 升级等

scope：（可忽略）

表示此次提交影响的范围，比如按照功能分模块的某个功能，几个功能并列写出

description ：

不超过50个字符。

推荐以动词开头，如： 设置、修改、增加、删减、撤销等

最后，给自己定下了标准就要遵守。。。。。20201125