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降级npmnpm 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 》