大家好，我是小橘，一个没有感情的码农。今天给大家介绍一下GitHooks。我相信每个人都在使用Git。除了用于版本控制，Git还有很多高级功能，GitHooks就是其中之一。本文环境：Git版本：2.27.0Husky版本：4.2.5Node.js版本：12.16.2前言做过前端的同学应该对Hook不陌生，后端也有Hook的概念，比如Java的@PostConstruct也是Hook的一种体现。简单的说，Hook就是在一个事件执行之前或者之后进行一些其他的额外操作。比如张三现在要吃饭，那么吃饭就是一个事件，吃饭前和吃饭后可以叫做两勾。现在你想让张三饭前洗手，那么我们可以在饭前钩上设置一个洗手动作。每次吃饭前，张三都会检查一下这个钩子，该做什么就做什么。这样，我们的需求就满足了。Git也是如此。Git中有很多事件（commit、push等），每个事件也对应着不同的hook（比如commit之前，commit之后），那么我们就可以在这些hooks中配置一些自己需要执行的Actions以满足各种要求。使用真实场景的同学可能第一次接触GitHooks会有一些疑问：这个东西能做什么？我以前没用过，不是一样好吗？我为什么要使用它？事实上，这是千真万确的。任何技术都需要被采用。如果没有需求，不要强求。永远记住：技术服务于商业。但这并不妨碍你先了解它。毕竟只有先知道这个技术能解决什么样的问题，以后遇到相应的问题时，才会知道用什么技术来解决。这里我给出一个真实的场景，我们团队在开发LinUI的时候遇到的：我们的Git仓库里面有编译后的代码，所以我们每次修改源码的时候，都需要运行编译命令，然后把源码和编译后的代码一起提交到Git仓库，这个过程没有任何问题。但是，人脑不是电脑，总会有疏忽的，经常会出现这样的情况：修改了源码，却忘了运行编译命令，最后只有将源码提交到Git仓库，从而得到在线仓库的源代码和编译。不一致的产品。虽然这个问题不是特别严重，但如果一直发生，总是不好的。于是我们想了一个办法，不再手动编译，把编译任务交给CI，这样就不会有这个问题了。但是事情并不总是那么顺利，因为我们在本地开发调试的时候需要对代码进行编译，所以会生成一部分编译后的代码。在使用Git的时候，我们经常会用到gitadd。命令，会把所有修改过的代码提交到仓库，这说明不可以。因为现在我们已经把编译交给了CI，为了方便CodeReview，编译好的代码应该不会再提交到仓库了。如果每次都手动去掉编译好的代码很麻烦，怎么办？在这种情况下，我们可以使用GitHooks来帮助我们在每次提交前自动移除已编译的代码。PS：虽然这种场景不是那么普遍和常见，但是在开发中确实遇到过。GitHooks介绍GitHooks的实现其实很简单，就是在.git/hooks文件下保存一些shell脚本，然后在对应的hooks中执行这些脚本。比如下图中，这是一个没有配置GitHooks的仓库。默认情况下，会有许多以.sample结尾的文件。这是一个例子。一些格式检查已经完成。该脚本默认不生效。如果需要生效，将文件名改为pre-commit.sample。pre-commit是一个钩子，在执行gitcommit命令之前触发Git。所有支持的hook如下表所示（粗体为常用hook）：GitHook调用时机说明pre-applypatchgitam执行前applypatch-msggitam执行前post-applypatchgitam执行不影响git的结果ampre-commitgitcommitexecution您可以在提交前使用gitcommit--no-verify来绕过commit-msggit。在执行gitcommit之前，可以使用gitcommit--no-verify来绕过post-commit。gitcommit执行后，gitcommit的结果不会受到影响。Pre-merge-commit可以在gitmerge之前执行绕过gitmerge--no-verify。执行prepare-commit-msggitcommit后，打开编辑器前，pre-rebase，执行gitrebase前，post-checkout，执行gitcheckout或gitswitch后，如果不带--no-checkout参数used，在gitclone之后也会执行。执行post-mergegitcommit后，执行gitpull时也会调用。pre-pushgitpush在执行pre-receivegit-receive-pack之前执行。updatepost-receivegit-receive-pack不影响git-receive-packpostafterexecution-updatepush-to-checkout当git-receive-pack响应gitpush更新仓库中的refspush-to-checkout当`git-receive-pack响应gitpush并更新存储库中的refs时，当push尝试更新当前签出的分支时，receive.denyCurrentBranch配置设置为updateInsteadpre-auto-gcgitgc--autoexecutionbeforepost-rewrite执行gitcommit--amend或gitrebasesendemail-validategitsend-email前执行fsmonitor-watchman配置core.fsmonitorp4-pre时设置为.git/hooks/fsmonitor-watchman或.git/hooks/fsmonitor-watchmanv2-submit可以用git-p4submit--no-verifybeforegit-p4submitexecute绕过p4-prepare-changelistgit-p4submit执行后，可以用git-p4submit--no-verifybeforeeditorstarts绕过p4-changelistgit-p4提交执行并编辑更改列表消息。可以使用git-p4submit--no-verify绕过p4-post-changelistgit-p4submit执行后，post-index-change索引写入read-cache.cdo_write_locked_index之后PS:完整的hook说明，请参考官网链接Husky配置通过上面的介绍，我们知道GitHooks存放在.git文件夹中。不知道大家有没有发现这个问题？细心的同学可能已经知道Git是一个多人协作的工具，所以按理说应该对Git仓库中的所有文件进行跟踪并上传到远程仓库。但是有一个例外，.git文件夹不会，这就导致了一个问题。我们在本地配置好GitHook后，如何分享给其他朋友呢？复制吗？那太低了。用的是git，copy太不雅了。这时候轮到哈士奇上场了。Husky是一个可以更方便配置Githooks的工具（题外话：Husky是哈士奇的意思，我猜作者可能养了两哈）下面的热门项目都在用Husky，可见它确实是一个非常好用的工具:webpackbabelcreate-react-app...Husky的原理是让我们在项目根目录下写一个配置文件，然后在安装Husky的时候把配置文件和GitHook关联起来，这样我们就可以在团队中使用Git挂钩。让我们开始配置Husky。第一步是使用npm初始化你的项目（如果项目已经有package.json，请跳到第二步）npminit-y第二步是安装Husky//注意Node.js版本必须be>=10npminstallhusky-D第三步，编写配置文件。4.2.5版本的Husky支持以下格式的配置文件：.huskyrc.huskyrc.json.huskyrc.yaml.huskyrc.yml.huskyrc.jshusky.config.js个人习惯，这里我使用.huskyrc，写配置json格式在里面，如下：{"hooks":{"pre-commit":"gitrestore-W-Sdistexamples/dist"}}是不是很简单，我们来解读一下这个配置文件。hooks对象中，key为钩子名，value为要执行的命令。上面配置的意思是在每次执行gitcommit之前，dist和examples/dit目录下的改动都会回滚（这两个目录是编译后的代码），所以不用担心提交编译错的代码在仓库里。上面我们只写了一条命令，如果我们要执行两条命令呢？比如我也想在gitcommit之前用EsLint检查代码质量，我们可以这样写：{"hooks":{"pre-commit":"gitrestore-W-Sdistexamples/dist&&eslint.“}}是的，就这么简单。如果EsLint测试失败，gitcommit会被阻塞，不用担心“垃圾代码”被提交到线上仓库。Husky笔记Husky可以让我们非常方便的配置GitHooks。同时也提供了一些实用方便的小技巧和一些我们需要注意的地方。不支持的钩子Husky不支持服务器端Git钩子：pre-receiveupdatepost-receive跳过所有钩子有时你可能不想运行钩子，所以你可以像这样跳过它们：HUSKY_SKIP_HOOKS=1gitrebase...禁用自动安装如果你不想让Husky自动帮你安装hooks（比如克隆了一个第三方库，想要自己开发的时候），可以这样做：HUSKY_SKIP_INSTALL=1npminstall最后，本文介绍一下什么是GitHooks,并讲解了如何使用Husky方便的配置GitHooks。在下一篇文章中，我将教大家如何使用commitlint结合Husky对团队的commit信息进行标准化。感兴趣的记得关注我哦！我是小菊，欢迎关注我的微信公众号，我会带你了解更多的前后端知识。
