commintlint是一个npm包用来规范化我们的commit信息，当然这个行为的操作时期是在git的commit-msg生命周期期间，这一点当然是有husky来控制，需要注意的是commit-msg作为一个git生命周期会被git commit和git merge行为唤醒，并且可以通过git命令后缀跳过这一生命周期
一、准备工作
1.下载一下commitlint
npm install --save-dev @commitlint/config-conventional @commitlint/cli这个命令下载了两个东西，@commitlint/cli实际上是commintlint的别名，就是包的本体，@commitlint/config-convebtional实际上是默认的配置，后面会在配置表中extend字段进行注入
2.配置一下commintlint
这边的话我直接贴一下网上找来的配置，创建commitlint.config.js，并写下如下内容（网上找的，暂时看看）
export default {
extends: ['@commitlint/config-conventional'],
rules: {
"type-enum": [2, 'always', [
'feat', 'fix', 'docs', 'perf', 'revert', 'ci', 'test', 'refactor', 'build', 'style', 'chore'
]],
'type-case': [0],//type 的输入格式,默认为小写‘lower-case’
'type-empty': [0],//type 是否可为空
'scope-empty': [0],//scope 是否为空
'scope-case': [0],//scope 的格式,默认为小写‘lower-case’
'subject-full-stop': [0, 'never'],//subject 结尾符,默认为.
'subject-case': [0, 'never'],//subject 的格式，默认其中之一：['sentence-case', 'start-case', 'pascal-case', 'upper-case']
'header-max-length': [0, 'always', 72]//header 最大长度，默认为72字符
},
};
3.创建husky的commit-msg钩子
我是分了两个步骤
npx husky add .husky/commit-msg然后在这个钩子中写入
npx --no -- commitlint --edit二、尝试一下写一个错误的提交
git commit -m "testhh"看一下有什么错误
我们的commintlint果然很严格呢
三、什么才是合格的提交
我们可以看一下@commitlint/config-conventional这个默认配置的npm页面上是怎么写的
说明一下我们上面的commitlint.config.js之中配置应该是自定义部分和@commitlint/config-conventional这个配置的融合版本
下面借一张图说一下每个项的一些配置涉及什么内容
上图是一个type-enum的配置，我们要配置的内容其实是value中的，condition代表了生效条件，也就是你的msg的类型一定要是在value之中，rule表示应该是检测的时机，这里是永远需要检测，level应该决定的是违反该规则是否报错，这样的话我们就能更好理解配置中每个内容了，这里其他配置默认配置我就不多说了。
那我们看一下我们写的commitlint.config.js里面的一些内容是啥意思
单说下面这个规则
"type-enum": [2, 'always', ['feat', 'fix', 'docs', 'perf', 'revert', 'ci', 'test','refactor', 'build', 'style', 'chore']]type-enum我们在上面见到过，它的value是一个数组，为啥这里的值是三个呢，前面那个2和always是啥意思？
实际上每个规则都有三个参数
level表示层级，0表示取消该规则，1表示违反该规则会导致warning，2表示违反规则会抛出一个错误
applicable的值则表示是否逆转这个规则，如 type-enum如果第二个参数写上never，则你提交的msg的type必须不在value的范围之内。
第三个value就是正常的value。
那么我们重看上面的我们在网上找的commitlint.config.js，里面的内容实际上就是取消了@commitlint/config-conventional这个默认配置表的一些规则，这样的话，我觉得如何定制自己的配置大概就有数了。
四、一个完整的正确的提交信息例子
build: 进行一次提交测试
这里是提交信息的body部分
这个我不知道干什么的footer部分注意这个“build:"后面有一个空格一定要写，你不写就提示你缺少subject
git有一个提交约定，可以看约定式提交
上面这个网页有详述 ，这样的话就可以理解上面的那些fix等等到底意味着什么，这里我就不写了
