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 npm
commitlint
-
装置依赖:
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》