（Git）pre-commit提交规范及commit-message校验
⼀、使⽤husky实现 pre-commit 提交规范
安装 lint-staged 和 husky
npm i lint-staged husky -D
在项⽬中初始化 .husky，会在 packgae.json 中添加 prepare 脚本
npm t-script prepare "husky install"&&npm run prepare
package.json
{
"scripts":{
"prepare":"husky install"
}
}
添加pre-commit hooks
运⾏以下命令创建git hooks
npx husky add .husky/pre-commit "npm run lint"
git add .husky/pre-commit
运⾏完该命令后我们会看到 .husky/ ⽬录下新增了⼀个名为 pre-commit 的shell脚本。也就是说在执⾏ git commit 命令时会先执⾏ pre-commit 这个脚本。pre-commit 脚本内容如下
#!/bin/shas long as you love me翻译
."$(dirname"$0")/_/husky.sh"
npm run lint
然后我们可以在 packgae.json 中添加 lint 脚本
{
"lint-staged":{
"*.{ts,tsx}":"eslint -c ./.it.json --fix"
},
"husky":{
"hooks":{
"pre-commit":"npm run lint-staged"
}
},
"scripts":{
"lint-staged":"lint-staged",
"lint":"npx eslint ./src"
}
}
这样在执⾏ git commit 的时候会先执⾏ pre-commit 这个脚本，pre-commit 脚本内执⾏ npm run lint 脚本就会执⾏ eslint
如果看到如下图的结果，那就做到ESLint 校验⽣效了，Husky 使⽤成功！！
⼆、Commit message 的格式
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
<type>(<scope>): <subject>// 空⼀⾏<body>// 空⼀⾏<footer>
其中，Header 是必需的，Body 和 Footer 可以省略。
不管是哪⼀个部分，任何⼀⾏都不得超过72个字符（或100个字符）。这是为了避免⾃动换⾏影响美观。
安装配置commitlint
yarn add @commitlint/cli @commitlint/config-conventional cz-conventional-changelog -D
package.json 中添加 lint 和 commitlint
leb
rolemodel@commitlint/cli 是commitlint提供的命令⾏⼯具，安装后会将cli脚本放置在./node_modules/.bin/⽬录下@commitlint/config-conventional是社区中⼀些共享的配置
...
"scripts":{
"lint":"npx eslint ./src",
monin"commitlint":"commitlint --config .commitlintrc.js -e -V",
},
"lint-staged":{
"*.{ts,tsx}":"eslint -c ./.it.json --fix"
},
"husky":{
"hooks":{
"pre-commit":"npm run lint-staged"
might}
},
"config":{
"commitizen":{
"path":"./node_modules/cz-conventional-changelog"
}
},
.
..
根⽬录添加 .commitlintrc.js .it.json .eslintrc.json ⽂件
.commitlintrc.js ⽂件
rules:{
'body-leading-blank':[1,'always'],
'footer-leading-blank':[1,'always'],
'header-max-length':[2,'always',72],
'scope-ca':[2,'always','lower-ca'],
'subject-ca':[2,'never',['start-ca','pascal-ca','upper-ca']],
'subject-empty':[2,'never'],
'subject-full-stop':[2,'never','.'],
'type-ca':[2,'always','lower-ca'],
'type-empty':[2,'never'],
'type-enum':[2,'always',['build','chore','ci','docs','feat','fix','perf','refactor','revert','style','test']]
}
}
.it.json ⽂件
{
"extends":"./.eslintrc.json",
"rules":{
"no-console":"error",wander
趣多多广告歌
"no-debugger":"error",
"no-alert":"error",
"camelca":"error",
"react-hooks/exhaustive-deps":"error",
"@typescript-eslint/no-empty-interface":"error",
"@typescript-eslint/no-empty-function":"error",
"@typescript-eslint/no-unud-vars":"error"
}
}
.eslintrc.json ⽂件
{
"extends":"react-app",
"rules":{
"no-console":"warn",
"no-debugger":"warn",
"no-alert":"warn",
"camelca":"warn",
"react-hooks/exhaustive-deps":"error",
"@typescript-eslint/no-empty-interface":"warn",
"@typescript-eslint/no-empty-function":"warn",
"@typescript-eslint/no-unud-vars":"warn"
}
}
Commit 的格式
地黄牛
有⼀个⽂档对 commit 的格式要求有个描述叫。下⾯就根据和对应，看看详细的说明。
每个 commit message 包含⼀个 header，body 和 footer。header 有⼀个特殊的格式包含有 type，scope 和 subject：这⾥主要引⽤header头部
Type
type ⽤于说明 commit 的类别，必须为以下类型的⼀种：
小学英语学习软件
主要type
feat: 增加新功能
fix: 修复bug
特殊type
docs: 只改动了⽂档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造⼯具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使⽤
revert: 执⾏git revert打印的message
暂不使⽤type
test: 添加测试或者修改现有测试
ymca是什么意思perf: 提⾼性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助⼯具的变动
Scope
scope ⽤于说明 commit 影响的范围，当影响的范围有多个时候，可以使⽤ *。
Subject
subject ⽤于对 commit 变化的简洁描述：
使⽤，⼀般以动词原形开始，例如使⽤ change ⽽不是 changed 或者 changes
第⼀个字母⼩写
结尾不加句号（.）
注意：git commit -m “feat: messge”,⽤双引号, 此次提交的简要描述，必须在 type 后⾯冒号之后的⼀个空格之后，结尾没有句号。
失败的案例:
成功的案例：
