共计 3313 个字符，预计需要花费 9 分钟才能阅读完成。
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 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 npmcommitlint
-
装置依赖：
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 的编码格局
husky
-
装置依赖：
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的文件构造
至此，不符合规范的 commit 将不再可提交：
那么到这里咱们的 规范化指标 就实现了吗？
当然没有！
当初咱们还短少一个 规范化的解决 ，那就是 代码格局提交标准解决！
有敌人看到这里可能说，咦！这个怎么看着这么眼生啊？这个事件咱们之前不是做过了吗？还须要在解决什么？
请看下一节分享《标准化编程标准解决方案之 pre-commit》
