精英团队设计中,每一个人 git commit 的好习惯都不一样,如此不益于对升级日志的挑选,也能够防止朋友逃走后,发生 bug 后,不明白他在当时递交的日志到底是改了一个 bug 或是增加了一个作用,危害研发效率。
这个时候就需要使用 git commit 递交规范化的专用工具。为什么一定要用专用工具标准,界定个递交规范化的文本文档,让大家都自主遵循不就行了。这样的想法是美好的,实际却非常骨感美,在发散思维以后,头脑乏了,就可能忘掉公司制度的递交格式规范,习惯性用自己以前的递交习惯性,导致不必要的损失。
工具的使用进行规范,假如递交的格式有误,会给出相对应提示,也不能将 commit 开展递交,必须改动成恰当格式 commit 才可以安全提交到 git 库房。
配备 commitlint
commitlint 能够查验你 git commit 日志是否满足你配备的标准,这与标准 JavaScript 格式 Eslint 非常像。commitlint 是一个 npm 里的专用工具,因此需要在 npm init
复位以后项目才能进行。
当需要限定 git commit 项目下组装 commitlint :
npm install --save-dev @commitlint/config-conventional @commitlint/cli
安装完成后,在工程目录下,新创建一个 .commitlintrc.json
文档,载入如下所示配备。
{ "extends": ["@commitlint/config-conventional"] }
extends
特性,意味着传承某一配备,上面继承 @commitlint/config-conventional
这一环境变量,把它当做默认配置文档就可以。
配备 husky
husky 是一个 git hook 专用工具,这个软件,还可以在 git 实行一些指令以前或是后再添加一些我们自己指令,学习过 vue 的,可以理解为是 git 的生命周期函数专用工具。
在目前新项目下组装 husky :
npm install husky --save-dev
激话 hook ,执行完下边的指令后,会到新项目目录下建立出一个名称 .husk
我文件夹名称,里面是储放 hook 脚本制作的区域:
npx husky install
添加一个 hook,就和 vue 写了个 onMounted
方式相近,实行完了,.husky
文件夹名称下面会多加一个 commit-msg
的脚本文件:
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'
这一句指令大致意思便是,在实施 git commit -m 'xxx'
这一句指令时,应用 commitlint
查验 'xxx'
内容文件格式是否满足标准。不符标准,会终止 git commit -m
并导出报错。
这样一个基本的 git commit 文件格式校检就配备好啦,随意 git add
一些文档,随后实行 git commit -m 'xxx'
试一下实际效果,下面我直接放官方事例:
saltedfish@DESKTOP-623RCE5 MINGW64 /d/code/commitlint-demo (master)
$ git add .
saltedfish@DESKTOP-623RCE5 MINGW64 /d/code/commitlint-demo (master)
$ git commit -m "foo: this will fail"
⧗ input: foo: this will fail
✖ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]
✖ found 1 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
husky - commit-msg hook exited with code 1 (error)
第 6 行一开始就是递交时的出错,先提醒你递交内容就是啥,随后对你说 type
也只能是中括号里的这些,你写的 foo
不符合规矩的。当把 foo
改为中括号里的 build
、chore
或 ci
等,就可以根据文件格式校检,并正常的递交 commit
。
saltedfish@DESKTOP-623RCE5 MINGW64 /d/code/commitlint-demo (master)
$ git commit -m "chore: lint on commitmsg"
[master (root-commit) af3dffd] chore: lint on commitmsg
5 files changed, 2224 insertions( )
create mode 100644 .commitlintrc.json
create mode 100644 .gitignore
create mode 100644 .husky/commit-msg
create mode 100644 package-lock.json
create mode 100644 package.json
commitlint 规则配置
有时,默认规则配置,不太适合我们自己的新项目应用,这时候,就可以使用有关配备特性,配备适宜我们自己递交标准。充分了解标准怎么配置以前,必须先了解一下递交 commit 格式一些定义。
type(scope?): subject
body?
footer?
默认设置标准中,配备了五种在日志所使用的具体内容,type
、scoped
、subject
、body
和 footer
。在其中,type
和 subject
是必填。
type
是一些能够定制的递交种类,如新口作用(feat)、修补 Bug(fix)等,必须如何的格式能自己配备。subject
是简略叙述,实际上是平时大家git commit -m 'xxx'
输入具体内容。
scope
我不怎么应用,大约是用来填好一些更改了什么文件的标识什么的,body
是详尽描述,便是 git commit -m 'xxx'
时,自动换行以后写一些详细说明,一般我就不会写,有 subject
我便够用。footer
这一我就不太用,实际写些啥都不太清楚。
掌握完定义后,就可以去开展我们自己的配备了,只介绍一些比较常用的配备,假如递交时,遇到一些不喜欢的配备,能看官方文档相匹配配备开展关掉。
一开始咱们就配备了一个 extends
特性,这就是传承他人提前准备好的配备。
{ "extends": ["@commitlint/config-conventional"] }
假如我们应该遮盖 extends
的规则配置,此刻,就需要使用 rules
特性,rules
接收到的一个对象({}
) ,key 相匹配标准名,value 相匹配标准,是一个长度为 3 的二维数组([Level, Applicable, Value]
) 。
Level
有三个值,为0
时,意味着关掉此标准,1
时,是警示,2
是不正确。Applicable
数值为always | never
,为never
时,翻转标准,应当是Level
三个值反过来的意思吧。Value
我就不多说了,便是配备的值。
下面演试一个常用配备 rules['type-enum']
,初始值是 ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'revert']
,便是上面讲到的 type
只有填什么值。
{
"extends": ["@commitlint/config-conventional"],
"rules": {
"type-enum": [
2,
"always",
[
"✨ 特色功能",
"
声明:本文仅供个人学习使用,来源于互联网,本文有改动,本文遵循[BY-NC-SA]协议, 如有侵犯您的权益,请联系本站,本站将在第一时间删除。谢谢你