关于vue.js:标准化编程规范解决方案之Git-Hooks

3次阅读

共计 3313 个字符，预计需要花费 9 分钟才能阅读完成。

上一节中咱们应用了 git cz 来代替了 git commit 实现了规范化的提交诉求，然而仍然存在着有人会遗记应用的问题。

那么这一节咱们就来看一下这样的问题，咱们应该如何去进行解决。

先来明确一下咱们最终要实现的成果：

咱们心愿：

当《提交形容信息》不合乎约定式提交标准的时候，阻止以后的提交，并抛出对应的谬误提醒

而要实现这个目标，咱们就须要先来理解一个概念，叫做 Git hooks（git 钩子 || git 回调办法）

也就是：git 在执行某个事件之前或之后进行一些其余额定的操作

而咱们所冀望的 阻止不合规的提交音讯，那么就须要应用到 hooks 的钩子函数。

上面是我整理出来的所有的 hooks，大家能够进行一下参考，其中加粗的是罕用到的 hooks：

Git Hook	调用机会	阐明
pre-applypatch	`git am`执行前
applypatch-msg	`git am`执行前
post-applypatch	`git am`执行后	不影响 `git am` 的后果
pre-commit	`git commit`执行前	能够用 `git commit --no-verify` 绕过
commit-msg	`git commit`执行前	能够用 `git commit --no-verify` 绕过
post-commit	`git commit`执行后	不影响 `git commit` 的后果
pre-merge-commit	`git merge`执行前	能够用 `git merge --no-verify` 绕过。
prepare-commit-msg	`git commit`执行后，编辑器关上之前
pre-rebase	`git rebase`执行前
post-checkout	`git checkout`或 `git switch` 执行后	如果不应用 `--no-checkout` 参数，则在 `git clone` 之后也会执行。
post-merge	`git commit`执行后	在执行 `git pull` 时也会被调用
pre-push	`git push`执行前
pre-receive	`git-receive-pack`执行前
update
post-receive	`git-receive-pack`执行后	不影响 `git-receive-pack` 的后果
post-update	当 `git-receive-pack`对 `git push` 作出反应并更新仓库中的援用时
push-to-checkout	当 `git-receive-pack 对`git push`做出反馈并更新仓库中的援用时，以及当推送试图更新以后被签出的分支且 `receive.denyCurrentBranch` 配置被设置为 `updateInstead` 时
pre-auto-gc	`git gc --auto`执行前
post-rewrite	执行 `git commit --amend` 或`git rebase`时
sendemail-validate	`git send-email`执行前
fsmonitor-watchman	配置 `core.fsmonitor` 被设置为 `.git/hooks/fsmonitor-watchman` 或`.git/hooks/fsmonitor-watchmanv2`时
p4-pre-submit	`git-p4 submit`执行前	能够用 `git-p4 submit --no-verify` 绕过
p4-prepare-changelist	`git-p4 submit`执行后，编辑器启动前	能够用 `git-p4 submit --no-verify` 绕过
p4-changelist	`git-p4 submit`执行并编辑完 `changelist message` 后	能够用 `git-p4 submit --no-verify` 绕过
p4-post-changelist	`git-p4 submit`执行后
post-index-change	索引被写入到 `read-cache.c do_write_locked_index` 后

PS：具体的 HOOKS 介绍 可点击这里查看

整体的 hooks 十分多，过后咱们其中用的比拟多的其实只有两个：

Git Hook	调用机会	阐明
pre-commit	`git commit`执行前它不承受任何参数，并且在获取提交日志音讯并进行提交之前被调用。脚本 `git commit` 以非零状态退出会导致命令在创立提交之前停止。	能够用 `git commit --no-verify` 绕过
commit-msg	`git commit`执行前可用于将音讯规范化为某种我的项目规范格局。还可用于在查看音讯文件后回绝提交。	能够用 `git commit --no-verify` 绕过

简略来说这两个钩子：

commit-msg：能够用来规范化规范格局，并且能够按需指定是否要回绝本次提交
pre-commit：会在提交前被调用，并且能够按需指定是否要回绝本次提交

而咱们接下来要做的要害，就在这两个钩子下面。
应用 husky + commitlint 查看提交形容是否符合规范要求

在上一大节中，咱们理解了 git hooks 的概念，那么接下来咱们就应用 git hooks 来去校验咱们的提交信息。

要实现这么个指标，那么咱们须要应用两个工具：

commitlint：用于查看提交信息
husky：是 git hooks 工具

留神：npm 须要在 7.x 以上版本！！！！！

查看 npm 版本
npm -v

降级 npm
npm i -g npm

装置依赖：

npm install --save-dev @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4

创立 commitlint.config.js 文件

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

关上 commitlint.config.js，减少配置项（config-conventional 默认配置点击可查看）：

module.exports = {
  // 继承的规定
  extends: ['@commitlint/config-conventional'],
  // 定义规定类型
  rules: {
    // type 类型定义，示意 git 提交的 type 必须在以下类型范畴内
    'type-enum': [
      // 以后验证的谬误级别，2 代表谬误级别的谬误
      2,
      // 在什么状况下进行验证，always 示意任何状况下都进行验证
      'always',
      // 泛型内容, 对应 cz-config 定义的 types
      [
        'feat', // 新性能 feature
        'fix', // 修复 bug
        'docs', // 文档正文
        'style', // 代码格局(不影响代码运行的变动)
        'refactor', // 重构(既不减少新性能，也不是修复 bug)
        'perf', // 性能优化
        'test', // 减少测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'build' // 打包
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

留神：确保保留为 UTF-8 的编码格局

装置依赖：
```
npm install husky@7.0.1 --save-dev
```
启动 hooks，生成 .husky 文件夹
```
npx husky install
```
在 package.json 中生成 prepare 指令（须要 npm > 7.0 版本）
```
npm set-script prepare "husky install"
```
执行 prepare 指令
```
npm run prepare
```
执行胜利，提醒
增加 commitlint 的 hook 到 husky中，并指令在 commit-msg 的 hooks 下执行 npx --no-install commitlint --edit "$1" 指令
```
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit"$1"'
```
此时的 .husky 的文件构造