Git 钩子
大约 8 分钟
Git 钩子是在 Git 仓库中特定事件发生时自动运行的脚本。可以定制一些钩子，这些钩子可以在特定的情况下被执行，分为 Client 端的钩子和 Server 端的钩子。客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。
# 安装一个钩子
钩子都被存储在 Git 目录下的 hooks 子目录中。即绝大部分项目中的 .git/hooks。
当你用 git init 初始化一个新版本库时，Git 默认会在这个目录中放置一些示例脚本。 这些脚本除了本身可以被调用外，它们还透露了被触发时所传入的参数。 移除后缀后就能启用。
把一个正确命名（不带扩展名）且可执行的文件放入 .git 目录下的 hooks 子目录中，即可激活该钩子脚本。
# 常用的钩子
pre-commit、pre-commit脚本在每次你运行git commit命令时，Git 向你询问提交信息或者产生提交对象时被执行。prepare-commit-msg、prepare-commit-msg钩子在pre-commit钩子在文本编辑器中生成提交信息之后被调用。这被用来方便地修改自动生成的squash或merge提交。commit-msg、commit-msg钩子和prepare-commit-msg钩子很像，但它会在用户输入提交信息之后被调用。post-commit、post-commit钩子在commit-msg钩子之后立即被运行。post-checkout、post-checkout钩子和post-commit钩子很像，但它在你用git checkout查看引用的时候被调用。pre-rebase、pre-rebase钩子在git rebase发生更改之前运行。pre-receive、pre-receive钩子在有人用git push向仓库推送代码时被执行。update、update钩子在pre-receive之后被调用，分别被每个推送上来的引用分别调用。post-receive、post-receive钩子在成功推送后被调用，适合用于发送通知。
# 客户端钩子
客户端钩子分为很多种。下面把它们分为：提交工作流钩子、电子邮件工作流钩子和其它钩子。
# 提交工作流钩子
前四个钩子涉及提交的过程。
pre-commit钩子在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。prepare-commit-msg钩子在启动提交信息编辑器之前，默认信息被创建之后运行。它允许你编辑提交者所看到的默认信息。该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。commit-msg钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。post-commit钩子在整个提交过程完成后运行。 它不接收任何参数，但你可以很容易地通过运行git log -1 HEAD来获得最后一次的提交信息。该钩子一般用于通知之类的事情。
# 电子邮件工作流钩子
你可以给电子邮件工作流设置三个客户端钩子。它们都是由 git am 命令调用的，如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。
第一个运行的钩子是 applypatch-msg。它接收单个参数：包含请求合并信息的临时文件的名字。如果脚本返回非零值，Git 将放弃该补丁。你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。
下一个在 git am 运行期间被调用的是 pre-applypatch。 有些难以理解的是，它正好运行于应用补丁之后，产生提交之前，所以你可以用它在提交前检查快照。你可以用这个脚本运行测试或检查工作区。如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。
post-applypatch 运行于提交产生之后，是在 git am 运行期间最后被调用的钩子。你可以用它把结果通知给一个小组或所拉取的补丁的作者。但你没办法用它停止打补丁的过程。
# 其它客户端钩子
pre-rebase 钩子运行于变基之前，以非零值退出可以中止变基的过程。你可以使用这个钩子来禁止对已经推送的提交变基。
post-rewrite 钩子被那些会替换提交记录的命令调用，比如 git commit --amend 和 git rebase（不过不包括 git filter-branch）。它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。这个钩子的用途很大程度上跟 post-checkout 和 post-merge 差不多。
在 git checkout 成功运行后，post-checkout 钩子会被调用。你可以根据你的项目环境用它调整你的工作目录。其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作。
在 git merge 成功运行后，post-merge 钩子会被调用。 你可以用它恢复 Git 无法跟踪的工作区数据，比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。
pre-push 钩子会在 git push 运行期间，更新了远程引用但尚未传送对象时被调用。它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。你可以在推送开始之前，用它验证对引用的更新操作（一个非零的退出码将终止推送过程）。
Git 的一些日常操作在运行时，偶尔会调用 git gc --auto 进行垃圾回收。pre-auto-gc 钩子会在垃圾回收开始之前被调用，可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。
# 服务器端钩子
除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。 这些钩子脚本在推送到服务器之前和之后运行。推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。
pre-receive
处理来自客户端的推送操作时，最先被调用的脚本是pre-receive。 它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。你可以用这个钩子阻止对引用进行非快进（non-fast-forward）的更新，或者对该推送所修改的所有引用和文件进行访问控制。
update
update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。
post-receive
post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。它接受与 pre-receive 相同的标准输入数据。它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器， 或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。 该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态， 所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。