在多人协作项目中,如果代码风格统一、代码提交信息的说明准确,那么在后期协作以及Bug处理时会更加方便。
因此,在本文章中,我会介绍怎么使用下面这个工具,在git push
代码之前检测commit messages
:
注意冒号后面有空格。
用于说明 commit 的类别,只允许使用下面7个标识。
feat
:新功能(feature)fix
:修补bugdocs
:文档(documentation)style
: 格式(不影响代码运行的变动)refactor
:重构(即不是新增功能,也不是修改bug的代码变动)test
:增加测试chore
:构建过程或辅助工具的变动如果type为feat
和fix
,则该 commit 将肯定出现在 Change log 之中。
subject是 commit 目的的简短描述,不超过50个字符,且结尾不加句号(.)。
npm install -g @commitlint/cli @commitlint/config-conventional
这个文件在根目录下生成就可以了。
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
"module.exports = {extends: ['@commitlint/config-conventional']}"
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', [
"feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"
]],
'subject-full-stop': [0, 'never'],
'subject-case': [0, 'never']
}
};
上面我们就完成了commitlint的安装与提交规范的制定。检验commit message的最佳方式是结合git hook,所以需要配合Husky
husky继承了Git下所有的钩子,在触发钩子的时候,husky可以阻止不合法的commit,push等等。注意使用husky之前,必须先将代码放到git 仓库中,否则本地没有.git文件,就没有地方去继承钩子了。
npm install husky --save-dev
安装成功后需要在项目下的package.json中配置
"scripts": {
"commitmsg": "commitlint -e $GIT_PARAMS",
},
"config": {
"commitizen": {
"path": "cz-customizable"
}
},
最后我们可以正常的git操作
git add .
git commit -m ""
git commit的时候会触发commlint。下面演示下不符合规范提交示例:
F:\accesscontrol\access_control>git commit -m "featdf: aas"
husky > npm run -s commitmsg (node v8.2.1)
⧗ input:
featdf: aas
✖ type must be one of [feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert] [type-enum]
✖ found 1 problems, 0 warnings
husky > commit-msg hook failed (add --no-verify to bypass)
F:\accesscontrol\access_control>
上面message不符合提交规范,所以会提示错误。
我们修改下type
F:\accesscontrol\access_control>git commit -m "feat: 新功能"
husky > npm run -s commitmsg (node v8.2.1)
⧗ input: feat: 新功能
✔ found 0 problems, 0 warnings
[develop 7a20657] feat: 新功能
1 file changed, 1 insertion(+)
F:\accesscontrol\access_control>
commit成功。
可以在package.json下面添加如下的钩子。
"husky": {
"hooks": {
"pre-commit": "npm run lint"
}
},