GIt Hooks (2)：脚本分类

上篇中提到一个Git Hooks列表，以下：

• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• pre-rebase
• post-checkout
• post-merge
• pre-receive
• update
• post-receive
• post-update
• pre-auto-gc
• post-rewrite

这些脚本能够按照运行环境分为两类：本地Hooks与服务端Hooks。

Client Side

也就是上面提到的本地hooks。
其实本地hooks仍是占大多数的，能够给它们分红三类：

• commit hooks
• e-mail hooks
• 其余

Commit Hooks

与git commit相关的hooks一共有四个，均由git commit命令触发调用，按照一次发生的顺序分别是：

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit

其中，pre-commit是最早触发运行的脚本。在提交一个commit以前，该hook有能力作许多工做，好比检查待提交东西的快照，以确保这份提交中没有缺乏什么东西、文件名是否符合规范、是否对这份提交进行了测试、代码风格是否符合团队要求等等。
这个脚本能够经过传递--no-verify参数而禁用，若是脚本运行失败（返回非零值），git提交就会被终止。

prepare-commit-msg脚本会在默认的提交信息准备完成后但编辑器还没有启动以前运行。
这个脚本的做用是用来编辑commit的默认提交说明。
该脚本有1~3个参数：包含提交说明文件的路径，commit类型（message, template, merge, squash），一个用于commit的SHA1值。这个脚本用的机会不是太多，主要是用于能自动生成commit message的状况。
该不会由于--no-verify参数而禁用，若是脚本运行失败（返回非零值），git提交就会被终止。

commit-msg包含有一个参数，用来规定提交说明文件的路径。
该脚本能够用来验证提交说明的规范性，若是做者写的提交说明不符合指定路径文件中的规范，提交就会被终止。
该脚本能够经过传递--no-verify参数而禁用，若是脚本运行失败（返回非零值），git提交就会被终止。

post-commit脚本发生在整个提交过程完成以后。这个脚本不包含任何参数，也不会影响commit的运行结果，能够用于发送new commit通知。

须要注意到，这几个脚本并不会经过clone传到项目中，并且既然是彻底运行在本地，那就没法彻底保证验证能起到做用（能够随便修改），但为了保证一些项目的可靠性，还须要开发者们自觉遵照这些规则。

E-mail Hooks

与git am相关的脚本由三个，均由git am触发运行，按顺序依次是：

• applypatch-msg
• pre-applypatch
• post-applypaych

若是在工做流中用不到这个命令，那也就无所谓了。不过，若是要用git format-patch命令经过Email提交补丁，这部份内容仍是比较有用的。

applypatch-msg脚本最早被触发，它包含一个参数，用来规定提交说明文件的路径。该脚本能够修改文件中保存的提交说明，以便规范提交说明以符合项目标准。若是提交说明不符合规定的标准，脚本返回非零值，git终止提交。

说明一点，这个脚本看上去和commit-msg做用几乎同样。没错，默认状况下该脚本是这样写的：

#!/bin/sh
. git-sh-setup
test -x "$GIT_DIR/hooks/commit-msg" &&
    exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
:

也就是说，该脚本会调用commit-msg并执行。实际上，这一切都是可修改的。

pre-applypatch会在补丁应用后但还没有提交前运行。这个脚本没有参数，能够用于对应用补丁后的工做区进行测试，或对git tree进行检查。若是不能经过测试或检查，脚本返回非零值，git终止提交。
一样须要注意，git提供的此默认脚本中只是简单调用了pre-commit，所以在实际工做中须要视状况修改。

post-applypatch脚本会在补丁应用并提交以后运行，它不包含参数，也不会影响git am的运行结果。该脚本能够用来向工做组成员或补丁做者发送通知。

其余Hooks

• pre-rebase

由git rebase命令调用，运行在rebase执行以前，能够用来阻止任何已发发生过的提交参与变基（字面意思，找不到合适的词汇了）。默认的pre-rebase确实是这么作的，不过脚本中的next是根据Git项目自身而写的分支名，在使用过程当中应该将其改为本身的稳定分支名称。

• post-checkout

由git checkout命令调用，在完成工做区更新以后执行。该脚本由三个参数：以前HEAD指向的引用，新的HEAD指向的引用，一个用于标识这次检出是不是分支检出的值（0表示文件检出，1表示分支检出）。

也能够被git clone触发调用，除非在克隆时使用参数--no-checkout。在由clone调用执行时，三个参数分别为null, 1, 1。

这个脚本能够用于为本身的项目设置合适的工做区，好比自动生成文档、移动一些大型二进制文件等，也能够用于检查版本库的有效性。

• post-merge

由git merge调用，在merge成功后执行。该脚本有一个参数，标识合并是否为压缩合并。该脚本能够用于对一些Git没法记录的数据的恢复，好比文件权限、属主、ACL等。

Server Side

除了本地执行的Hooks脚本以外，还有一些放在Git Server上的Hooks脚本，做为管理员，能够利用这些服务端的脚原本强制确保项目的任何规范。这些运行在服务端的脚本，会在push命令发生的先后执行。pre系列的脚本能够在任什么时候候返回非零值来终止某次push，并向push方返回一个错误说明。

这里简单介绍这几个脚本：

• pre-receive

由服务器端的git receive-pack命令调用，当从本地版本库完成一个推送以后，远端服务器开始批量更新以前，该脚本被触发执行。该脚本会从标准输入中读入一连串push过来的引用，若是这里面存在任何非零值，这批更新将不会被服务器接受。能够利用这个脚原本检查推送过来的提交是否合法。

• post-receive

由服务器端的gir receive-pack命令调用，当从本地版本库完成一个推送，而且在远程服务器上全部引用都更新完毕后执行。该脚本能够用于对其余镜像版本库的更新，或向用户发送提示（直接经过服务器端的echo命令）。如上文我提到的利用Git实现生产代码的自动化部署，就能够经过这个脚本完成。

• update
  这是一个强大的hook脚本。它和pre-recieve有些相似，只是它会为推送过来的更新中涉及到的每个分支都作一次检查，然后者则至始至终只有一次检查。另外，它不是从标准输入中读取数据，而是包含三个参数：
  
  
  • 要更新的引用或分支的名称
  • 引用中保存的旧对象名称（SHA1）
  • 将要保存到引用中的新对象名称(SHA1)

若是检查到返回非零值，以后返回非零值的引用会被拒绝，其余正常的引用更新都会被接受。除此以外，该脚本还能够用来防止引用被强制更新，由于它能够经过这些参数来检查新旧引用对象中是否存在继承关系，从而提供更细致的推送受权。

在Gitolite中，该脚本有更强大的应用实例。

本篇完结，敬请期待后续……