在公司大多都使用git管理项目代码，在一个大的项目组中，会涉及很多的开发人员，这就会面临着频繁的提交代码。规范的提交代码规则会有利于问题的查找和回归，所以提交规范变得尤其的重要。而commitlint 和husky就能做到约束的效果，让同时配合更加事半功倍
注： 二者要结合使用哈
1. 首先相关npm包的安装
yarn add husky pre-commit lint-staged @commitlint/cli @commitlint/config-conventional husky -D
2. commitlint的配置文件
// commitlint.config.js
const types = [
'build', // 主要目的是修改项目构建系统（例如glup，webpack，rollup的配置等）的提交
'ci', // 修改项目的持续集成流程（Kenkins、Travis等）的提交
'chore', // 构建过程或辅助工具的变化
'docs', // 文档提交（documents）
'feat', // 新增功能（feature）
'fix', // 修复 bug
'pref', // 性能、体验相关的提交
'refactor', // 代码重构
'revert', // 回滚某个更早的提交
'style', // 不影响程序逻辑的代码修改、主要是样式方面的优化、修改
'test', // 测试相关的开发,
],
typeEnum = {
rules: {
'type-enum': [2, 'always', types],
},
value: () => {
return types;
},
};
module.exports = {
extends: ['@commitlint/config-conventional'],
/*
Level [0..2]: 0 disables the rule. For 1 it will be considered a warning for 2 an error.
https://commitlint.js.org/#/reference-rules
*/
rules: {
'type-enum': typeEnum.rules['type-enum'],
'subject-full-stop': [0, 'never'],
'subject-case': [0, 'never'],
}
}
3. husky配置
// package.json
// scripts下添加命令
"scripts": {
"prepare": "husky install"
}
// 根目录下执行
npm run prepare
// package.json文件第一层级添加如下代码：
"lint-staged": {
"*.{js,vue}": [
"prettier --write",
"eslint --fix"
]
},
"husky": {
"hooks": {
"pre-commit": "lint-staged",
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
根目录下执行命令，生成husky的hooks
// 大概是这意思
//npx husky add .husky/commit-msg 使用husky在.husky文件夹下添加是commit-msg的钩子
// 'npx --no -- commitlint --edit "$1"' 表示在调用该hook时候要执行的命令
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'
接下来提交commit时就会发现不按规范就会报错了，至此就ok了
