Hello Git（六）——Git钩子_git 钩子

一、Git钩子简介

与其它版本控制系统相同，Git也可以在特定的重要动作发生时触发自定义脚本。Git有两种类型的钩子:客户端钩子和服务器端钩子。客户端钩子由诸如提交和合并等操作所调用，而服务器端钩子作用于诸如接收被推送的提交等联网操作。

Git钩子都被存储在Git仓库目录（.git）下的hooks子目录中。当git init初始化一个新版本库时，Git 默认会在hooks目录中放置一些示例脚本。示例脚本除了本身可以被调用外，还透露了被触发时所传入的参数。所有的示例脚本都是shell脚本，可以使用Ruby、Python或其它语言编写脚本。

二、Git钩子安装

示例脚本的名字都以.sample结尾，如果要使用示例脚本，必须先移除.sample后缀。

把一个正确命名且可执行的钩子脚本文件放入Git目录下的 hooks子目录中，即可激活钩子脚本。钩子脚本激活后即可被Git调用。

 三、客户端钩子

客户端钩子分为提交工作流钩子、电子邮件工作流钩子和其它钩子。当克隆版本库时，客户端钩子并不会被随同复制。如果需要靠钩子脚本来强制维持某种策略，建议在服务器端实现。

1、提交工作流钩子

A、pre-commit钩子

pre-commit钩子在键入提交信息前运行，用于检查即将提交的快照，例如检查是否有所遗漏，确保测试运行以及核查代码。 如果pre-commit钩子以非零值退出，Git将放弃此次提交，但可以用 git commit --no-verify来绕过本环节。可以利用pre-commit钩子来检查代码风格是否一致、尾随空白字符是否存在或新方法的文档是否适当。

B、prepare-commit-msg钩子

prepare-commit-msg钩子在启动提交信息编辑器前，默认信息被创建后运行，允许编辑提交者所看到的默认信息。prepare-commit-msg钩子接收一些选项:存有当前提交信息的文件的路径、提交类型和修补提交的提交的SHA-1校验。 prepare-commit-msg钩子对一般的提交并没有什么用，但对会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。prepare-commit-msg钩子可以结合提交模板使用，动态地插入信息。

C、commit-msg钩子

commit-msg钩子接收一个参数，参数是存有当前提交信息的临时文件的路径。 如果commit-msg钩子脚本以非零值退出，Git将放弃提交。因此，可以用来在提交通过前验证项目状态或提交信息。

D、post-commit钩子

post-commit钩子在整个提交过程完成后运行，不接收任何参数，但可以很容易地通过运行git log -1 HEAD来获得最后一次的提交信息。post-commit钩子一般用于通知类的事情。

2、电子邮件工作流钩子

可以给电子邮件工作流设置三个客户端钩子，电子邮件工作流钩子由git am命令调用，因此如果在工作流中没有用到git am命令，不用设置。 如果需要通过电子邮件接收由git format-patch产生的补丁，可以使用电子邮件工作流钩子。

第一个运行的钩子是applypatch-msg，接收单个参数:包含请求合并信息的临时文件的名字。如果脚本返回非零值，Git 将放弃该补丁。可以用applypatch-msg脚本来确保提交信息符合格式或直接用脚本修正格式错误。

第二个在git am运行期间被调用的是pre-applypatch脚本，正好运行于应用补丁后，产生提交前。因此，可以用于提交前检查快照。 可以用pre-applypatch脚本运行测试或检查工作区。 如果有遗漏或测试未能通过，pre-applypatch脚本会以非零值退出，中断git am的运行，补丁就不会被提交。

第三个在git am运行期间被调用的是post-applypatch脚本，运行于提交产生后，是在git am运行期间最后被调用的钩子。可以用于把结果通知给一个小组或所拉取的补丁的作者。 但post-applypatch脚本不能停止打补丁的过程。

3、其它客户端钩子

A、pre-rebase钩子

pre-rebase钩子运行于变基前，以非零值退出可以中止变基的过程。可以用于禁止对已经推送的提交变基。

B、post-rewrite钩子

post-rewrite钩子会被那些会替换提交记录的命令调用，比如git commit --amend和git rebase(不包括 git filter-branch)。 唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。

C、post-checkout钩子

在git checkout成功运行后，post-checkout钩子会被调用。可以根据开发者项目环境用于调整工作目录。其中包括放入大的二进制文件、自动生成文档或进行其它类似操作。

D、post-merge钩子

在git merge成功运行后，post-merge钩子会被调用。可以用于恢复Gi 无法跟踪的工作区数据，比如权限数据。post-merge钩子也可以用来验证某些在Git控制外的文件是否存在，使开发者能在工作区改变时，把文件复制进来。

E、pre-push钩子

pre-push钩子会在git push运行期间，已经更新远程引用但尚未传送对象时被调用。接收远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。在推送开始前，用pre-push钩子验证对引用的更新操作(一个非零的退出码将终止推送过程)。

F、pre-auto-gc钩子

Git的一些日常操作在运行时，偶尔会调用git gc --auto进行垃圾回收。 pre-auto-gc钩子会在垃圾回收开始前被调用，可以用于提醒开发者现在要回收垃圾或者依情形判断是否要中断回收。

四、服务器端钩子

作为系统管理员，可以使用若干服务器端的钩子对项目强制执行各种类型的策略。服务器端钩子脚本在推送到服务器前和后运行。推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以根据管理员所想设置足够复杂的推送策略。

A、pre-receive钩子

处理来自客户端的推送操作时，最先调用pre-receive钩子。 pre-receive钩子从标准输入获取一系列被推送的引用。

如果pre-receive钩子以非零值退出，所有的推送内容都不会被接受。 可以用于阻止对引用进行非快进(non-fast-forward)的更新或者对推送所修改的所有引用和文件进行访问控制。

B、update钩子

update脚本和 pre-receive脚本十分类似,不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容,pre-receive 只运行一次,相比之下 update 则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容,而是接受三个参数:引用的名字(分支),推送前的引用指向的内容的

SHA-1 值,以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出,只有相应的那一个引用会

被拒绝;其余的依然会被更新。

C、post-receive钩子

post-receive钩子在整个过程完结后运行，可以用来更新其它系统服务或者通知用户。接受与pre-receive相同的标准输入数据。 其用途包括给某个邮件列表发信，通知持续集成服务器或者更新问题追踪系统(ticket-tracking system) ，甚至可以通过分析提交信息来决定某个问题(ticket)是否应该被开启，修改或者关闭。post-receive钩子无法终止推送进程，客户端在post-receive钩子结束运行前将保持连接状态，所以如果想做其它操作需谨慎使用post-receive钩子，因为其会很耗时。