你好，我是小桔，是一个没有感情的代码崽。
今天给大家介绍一下 Git Hooks，相信 Git 大家都在用吧，Git 除了用作版本控制，还有许多高级功能，Git Hooks 就是其中之一。
> 本文环境： > > - Git 版本：2.27.0 > - Husky 版本：4.2.5 > - Node.js 版本：12.16.2
前言
做过前端的同学对 Hook 这个东西应该很了解吧，后端也是有 Hook 这种概念的，比如 Java 的@PostConstruct，也是一种 Hook 的体现。简单来说，Hook 就是在执行某个事件之前或之后进行一些其他额外的操作。
举个栗子，张三现在要吃饭，那么吃饭就是一个事件，吃饭前和吃饭后就可以称为两个钩子。现在你想让张三在吃饭前洗下手，那么我们就可以在吃饭前这个钩子这里，设置一个洗手的动作。张三在每次吃饭前，都会检查一下这个钩子，有什么要做的，都会照做。这样，就实现了我们的需求。
Git 也是如此，在 Git 中也有许多的事件（commit、push 等等），每个事件也是对应了有不同的钩子的（如 commit 前，commit 后），那么我们就可以在这些钩子这里配置一些自己需要执行的操作来实现各种各样的需求。
使用
真实场景
可能初次了解 Git Hooks 的同学会有一些疑问：这个东西到底能干嘛？我以前没用过它不也一样好好的吗？我干嘛要用它？
其实这说得很对，**任何技术都是有需求采用，没有需求就别去硬塞，永远记住：技术为业务服务。**但是这并不妨碍你先去了解它，毕竟，只有你先知道了这项技术能解决什么样的问题，日后当你遇到相应的问题时，你才知道该用什么技术去解决。
这里我给出一个真实的场景，是我们团队在开发 Lin UI 的时候遇到的：
我们的 Git 仓库中包含了编译后的代码，所以每次修改了源码，都需要运行一下编译命令，然后把源码和编译后的代码一起提交到 Git 仓库，这个流程没什么问题。但是，人脑不是电脑，总会有疏忽的时候，经常会出现这样一种情况：修改了源码，却忘记了运行编译命令，最后只把源码提交到了 Git 仓库，导致线上仓库的源码和编译产物不一致、
这个问题虽然不是特别严重，但老是出现也总归不好。所以我们就想了一个办法，不再手动编译，把编译任务交给 CI 去做，这样就不存在这样的问题。
但事情总是没那么顺利，因为我们在本地开发调试的时候是需要编译代码的，所以就会生成一部分编译代码，在使用 Git 时，我们经常会使用git add .命令，会把所有修改了的代码都提交到仓库，这显示是不行的。因为现在我们已经把编译交给 CI 去做了，并且为了 Code Review 方便，编译代码不应该再提交到仓库了。如果每次手动去把编译代码去除，又非常麻烦，那该怎么办呢？
这种情况，就可以使用 Git Hooks 帮我们在每次提交前自动把编译代码去掉了。
> PS：这个场景虽然不那么常见和通用，但确实是在开发中真实遇见的。
Git Hooks 介绍
Git Hooks 的实现其实非常简单，就是就.git/hooks文件下，保存了一些 shell 脚本，然后在对应的钩子中执行这些脚本就行了。比如下图中，这是一个还没有配置 Git Hooks 的仓库，默认会有很多.sample结尾的文件，这些都是示例文件
我们打开pre-commit.sample文件看一下其中的内容，大致意思是说这是一个示例，做了一些格式方面的检测，这个脚本默认是不生效的，如果要生效，把文件名改为pre-commit.sample即可
pre-commit这个钩子是在git commit命令执行之前触发
Git 支持的所有钩子见下表（加粗的为常用钩子）：
| 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：完整钩子说明，请参考官网链接
Husky 配置
从上面的介绍中，我们知道 Git Hook 保存在 .git 文件夹中。不知你有没有发现这会有一个问题？可能细心的同学已经知道了，Git 是一个多人协作工具，那按理说 Git 仓库中的所有文件都应该被跟踪并且上传至远程仓库的。但是有个例外，.git文件夹不会，这就导致一个问题，我们在本地配置好 Git Hook 后，怎么分享给其他小伙伴儿呢？copy 吗？那未免太 low 了，都用 Git 了，还 copy，也太不优雅了。这时候，就轮到 Husky 出场了。
Husky 是一个让配置 Git 钩子变得更简单的工具（题外话：Husky 是哈士奇的意思，我猜可能是作者养了条二哈）
下面这些流行的项目都在使用 Husky，可见它确实是一个非常好用的工具：
Husky 的原理是让我们在项目根目录中写一个配置文件，然后在安装 Husky的时候把配置文件和 Git Hook 关联起来，这样我们就能在团队中使用 Git Hook 了。
下面开始配置 Husky
第一步
使用 npm 初始化你的项目（如果项目已有 package.json，请跳至第二步）
npm init -y
第二步
安装 Husky
// 注意 Node.js 版本要 >=10
npm install husky -D
第三步
书写配置文件，4.2.5 版本的 Husky 共支持以下几种格式的配置文件：
- .huskyrc
- .huskyrc.json
- .huskyrc.yaml
- .huskyrc.yml
- .huskyrc.js
- husky.config.js
个人习惯，这里我采用的是.huskyrc，在其中书写 json 格式的配置，如下：
{
"hooks": {
"pre-commit": "git restore -W -S dist examples/dist"
}
}
是不是很简单，我们来解读一下这个配置文件。hooks这个对象中，key 就是钩子名，而 value 就是需要执行的命令。上面这个配置的含义就是，在每次执行 git commit之前，都会把dist和examples/dit目录下的修改回滚（这两个目录就是编译产生的代码），就不用担心误把编译后的代码提交到仓库中了。
上面我们只写了一条命令，如果想执行两条命令怎么办呢？比如我还想在git commit之前用 EsLint 检查一下代码质量，我们可以像下面这样写：
{
"hooks": {
"pre-commit": "git restore -W -S dist examples/dist && eslint ."
}
}
是的，就是这么简单。如果 EsLint 检测不通过，那么git commit是会被阻止的，就不用担心"垃圾代码"被提交到线上仓库了。
Husky 注意事项
Husky 让我们可以很方便的配置 Git Hooks，同时，也提供了一些实用方便的小技巧以及一些我们需要注意的点
不支持的钩子
Husky 不支持服务端 Git 的钩子：
- pre-receive
- update
- post-receive
跳过所有钩子
有时你可能不想运行钩子，那么可以像下面这样跳过：
HUSKY_SKIP_HOOKS=1 git rebase ...
禁用自动安装
如果你不想 Husky 为你自动安装钩子（比如 clone 了一个第三方的库，想要自己开发时），可以这样做：
HUSKY_SKIP_INSTALL=1 npm install
最后
本文介绍了 Git Hooks 具体有哪些，并讲解了如何用 Husky 便捷的配置 Git Hook。下一篇文章，我会教你如何用 commitlint 结合 Husky 来规范团队的 commit 信息，如果有兴趣的话，记得一定要关注我哦！
我是小桔，欢迎关注我的微信公众号，带你了解更多前后端知识。