乐趣区

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

Git Hooks

上一节中咱们应用了 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 checkoutgit 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-packgit push 作出反应并更新仓库中的援用时
push-to-checkout `git-receive-packgit push做出反馈并更新仓库中的援用时,以及当推送试图更新以后被签出的分支且 receive.denyCurrentBranch 配置被设置为 updateInstead
pre-auto-gc git gc --auto执行前
post-rewrite 执行 git commit --amendgit 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 绕过

简略来说这两个钩子:

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

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

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

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

  1. commitlint:用于查看提交信息
  2. husky:是 git hooks 工具

留神:npm 须要在 7.x 以上版本!!!!!

查看 npm 版本
npm -v

降级 npm
npm i -g npm

commitlint

  1. 装置依赖:

    npm install --save-dev @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4
  2. 创立 commitlint.config.js 文件

    echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
  3. 关上 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 的编码格局

husky

  1. 装置依赖:

    npm install husky@7.0.1 --save-dev
  2. 启动 hooks,生成 .husky 文件夹

    npx husky install

  3. package.json 中生成 prepare 指令(须要 npm > 7.0 版本

    npm set-script prepare "husky install"

  4. 执行 prepare 指令

    npm run prepare
  5. 执行胜利,提醒
  6. 增加 commitlinthookhusky中,并指令在 commit-msghooks 下执行 npx --no-install commitlint --edit "$1" 指令

    npx husky add .husky/commit-msg 'npx --no-install commitlint --edit"$1"'
  7. 此时的 .husky 的文件构造

至此,不符合规范的 commit 将不再可提交:

那么到这里咱们的 规范化指标 就实现了吗?

当然没有!

当初咱们还短少一个 规范化的解决 ,那就是 代码格局提交标准解决!

有敌人看到这里可能说,咦!这个怎么看着这么眼生啊?这个事件咱们之前不是做过了吗?还须要在解决什么?

请看下一节分享《标准化编程标准解决方案之 pre-commit》

退出移动版