Git规范化工具
本文最后更新于:6 个月前
(1)husky——增强git hook工具,更便捷地设置hooks脚本、(2)lint-staged——将linters运行范围限制在 git「暂存区」的辅助工具、(3)commitizen——commit message交互式输入工具,保证你的message输入符合规范、(4)commitlint——message规范检查工具
Git规范化工具
一、husky
官方文档:🐶 husky | 🐶 husky (typicode.github.io)
1. husky是什么
husky是一个npm模块,它的作用是用来在执行 git 命令时,自动触发自定义hooks脚本的执行。这些hooks脚本由用户创建,可以在不同的时机执行不同的操作,来完成诸如:lint commit message、lint code、运行测试脚本等等操作。如果脚本不通过,会阻止 git 命令的执行。
2. 使用入门
1 |
|
最后一条命令的结果是在package.json
中添加一条命令:
1 |
|
使用husky add <file> [cmd]
创建一个hook脚本
1 |
|
然后,使用commit
提交,husky会自动调用 pre-commit
这个hook脚本。
1 |
|
如果npm test
运行成功并且没有出错,commit
成功;否则commit
将被拦截
Tips:如果hooks脚本中调用了 exit 1 那么git 命令会被终止。可以利用这个特点来测试 hooks脚本
3. 跳过hooks脚本
如果在某些情况下,commit的时候想跳过执行 pre-commit
或commit-msg
脚本,可以使用-n
/--no-verify
参数
1 |
|
4. 卸载husky
1 |
|
如果只想删除某个脚本,将.husky/
目录下对应的hook文件删除即可!
二、lint-staged
npm官网:lint-staged - npm (npmjs.com)
1. lint-staged是什么
来看看官方介绍:
Run linters against staged git files,翻译:对暂存的git文件运行linters
它出现的背景是:随着Web项目体积越来越大,如果一次性对所有代码进行 Lint 的时间会越来越长,变得不可接受。所以提出一种策略:只对需要commit
的代码进行 Lint,因为已经提交的代码在之前已经通过了 Lint,这样可以大大缩短 Lint 的时间。lint-staged 就是用来实现这种策略的工具。
2. 如何使用
第一步,安装lint-staged
1 |
|
第二步,设置pre-commit
脚本,例如大多数人通过 husky 来设置。在/.husky/pre-commit
中设置:
1 |
|
第三步,安装所需的 linters 并完成配置,例如:ESLint、Prettier等
第四步,配置 lint-staged。支持多种配置方式,详情查看:lint-staged - Configuration,这里采用最简单的:在package.json
中配置,如下:
1 |
|
其中采用的匹配模式是glob pattern
。到此,项目中再次commit
时,就只会对git add
的内容运行各种linter命令了。
这里有更多的使用示例:lint-staged - Examples
三、commitizen
传送门:commitizen - npm (npmjs.com)
1. commitizen是什么
让我们来看看官方的介绍:
当您使用Commilizen提交时,系统将提示您在提交时填写任何必需的提交字段。而不用等到git commit之后触发hooks运行才拒绝你的commit(尽管这也能发挥作用)
它是一款命令行交互工具,通过提示你输入规定的message字段内容,来统一message的组成成分,就像下面这样:
2. 怎么用
第一步,安装(需要 npm 版本 >= 6),官方推荐全局安装(当然也可以作为开发依赖,在本地使用)
1 |
|
第二步,使用 commitizen 的命令 cz
,而不是原来的git commit
来做提交
1 |
|
如果你不想去记cz
这个命令,也可以在package.json
中自定义一个scripts
命令
1 |
|
这样以后只要输入npx commit
或npm run commit
就可以提交了。
但是这个时候去运行cz
命令的话,还起不到规范化的作用,因为还没有配置message规则。当前只会弹出编辑器让你编辑message(和git commit的表现一致)
然后随意输入一段内容,都能够完成commit(这显然不符合我们的需求)
所以,第三步,需要配置一套规则,官方教程推荐使用的是 AngularJS’s commit message convention,也被称为:conventional-changelog,关于它更通俗的介绍可以看这篇:Commit message 和 Change log 编写指南 - 阮一峰
1 |
|
1 |
|
上面这个path
告诉 commitizen 应该使用哪个适配器adapter
此时,再运行npx cz
命令,就会出现交互式提示了
查看刚刚输入的log信息,此时所做的修改便一目了然了。最关键的是,它现在是结构化的内容,你通过查看不同部分的内容就能够快速获取到想要的信息,比如修改的类型、范围、详细修改内容等等。
3. 进阶使用
上述我们介绍了使用npx cz
来替代git commit
命令来做提交,目的是为了使用到 commitizen 的功能。但是能不能既使用git commit
这个原始的命令,又能够触发 commitizen 的功能呢?答案是可以的(npm文档中有介绍,在 Optional: Running Commitizen on git commit
这一节)
1 |
|
这里使用的是 husky 工具。
但是实际使用效果并不好,命令行输出存在一些bug,所以只作简单了解。
4. commit类型
类型 | 解释 |
---|---|
feat | 新增特性(A new feature) |
fix | 修复bug(A bug fix) |
docs | 仅包含文档的修改(Documnetation only changes) |
style | 修改代码格式,不影响代码逻辑(white-space, formatting, missing semi colons, ect) |
refactor | 重构 (refactor) |
perf | 提高性能的修改(A code change that improves performance) |
test | 添加或修改测试代码(Adding missing tests or correcting existing tests) |
build | 构建工具或外部依赖包的更改(Changes that affect the build system or external dependencies) |
ci | 持续集成的配置文件或脚本的修改(Changes to our CI configuration files and scripts) |
chore | 杂项(Other changes that don’t modify src or test files) |
revert | 撤销某次提交(Reverts a previous commit) |
四、commitlint
官方文档:Local setup (commitlint.js.org)
1. commitlint是什么
commitlint 是一个 git commit 校验约束工具。在你使用git commit -m xxx
提交message之后,对message的内容做检查,如果不通过,commit会被拦截失效
2. 怎么用
第一步,安装
1 |
|
第二步,设置hook脚本,这里使用husky
1 |
|
commitlint --edit <文件名>
:执行 commitlint 命令行工具,并使用--edit
选项,从一个文件里提取 commit 内容来进行校验。校验规则由commitlint.config.js
配置文件来指定,$1
:在新版的 husky 中$HUSKY_GIT_PARAMS
变量已不再使用,取而代之是$1