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等等到底意味着什么,这里我就不写了