使用Git Hooks实现开发部署任务自动化

前言

版本控制，这是现代软件开发的核心需求之一。有了它，软件项目可以安全的跟踪代码变更并执行回溯、完整性检查、协同开发等多种操作。在各种版本控制软件中，Git是近年来最流行的软件之一，它的去中心化架构以及源码变更交换的速度被很多开发者青睐。

在git的众多优点中，最有用的一点莫过于它的灵活性。通过“hooks”（钩子）系统，开发者和管理员们可以指定git在不同事件、不同动作下执行特定的脚本。

本文将介绍git hooks的基本思路以及用法，示范如何在你的环境中实现自动化的任务。本文所用的操作系统是Ubuntu 14.04服务器版，理论上任何可以跑git的系统都可以用同样的方法来做。

前提条件

首先你的服务器上先要安装过git。Ubuntu 14.04的用户可以查看这篇教程了解如何在Ubuntu 14.04上安装git。

其次你应该能够进行基本的git操作。如果你觉得对git不太熟，可以先看看这个Git入门教程。

上述条件达成后，请继续往下阅读。

Git Hooks的基本思路

Git hooks的概念相当简单，它是为了一个单一需求而被设计实现的。在一个共享项目（或者说多人协同开发的项目）的开发过程中，团队成员需要确保其编码风格的统一，确保部署方式的统一，等等（git的用户经常会涉及到此类场景），而这些工作会造成大量的重复劳动。

Git hooks是基于事件的（event-based）。当你执行特定的git指令时，该软件会从git仓库下的hooks目录下检查是否有相对应的脚本，如果有则执行之。

有些脚本是在动作执行之前被执行的，这种“先行脚本”可用于实现代码规范的统一、完整性检查、环境搭建等功能。有些脚本则在事件之后被执行，这种“后行脚本”可用于实现代码的部署、权限错误纠正（git在这方面的功能有点欠缺）等功能。

总体来说，git hooks可以实现策略强制执行、确保一致性、环境控制、部署任务处理等多种功能。

Scott Chacon在他的Pro Git一书中将hooks划分为如下类型：

• 客户端的hook：此类hook在提交者（committer）的计算机上被调用执行。此类hook又分为如下几类：

  • 代码提交相关的工作流hook：提交类hook作用在代码提交的动作前后，通常用于运行完整性检查、提交信息生成、信息内容验证等功能，也可以用来发送通知。
  • Email相关工作流hook：Email类hook主要用于使用Email提交的代码补丁。像是Linux内核这样的项目是采用Email进行补丁提交的，就可以使用此类hook。工作方式和提交类hook类似，而且项目维护者可以用此类hook直接完成打补丁的动作。
  • 其他类：包括代码合并、签出（check out）、rebase、重写（rewrite）、以及软件仓库的清理等工作。

• 服务器端hook：此类hook作用在服务器端，一般用于接收推送，部署在项目的git仓库主干（main）所在的服务器上。Chacon将服务器端hook分为两类：

  • 接受触发类：在服务器接收到一个推送之前或之后执行动作，前触发常用于检查，后触发常用于部署。
  • 更新：类似于前触发，不过更新类hook是以分支（branch）作为作用对象，在每一个分支更新通过之前执行代码。

上述分类有助于我们对hook建立一个整体的概念，了解它可以用于哪类事件。当然了，要能够实际的运用它，还需要亲自动手操作、调试。

有些hook可以接受参数。也就是说，当git调用了hook的脚本时，我们可以传递一些数据给这个脚本。可用的hook列表如下：

Hook名称	触发指令	描述	参数的个数与描述
applypatch-msg	`git am`	可以编辑commit时提交的message。通常用于验证或纠正补丁提交的信息以符合项目标准。	(1) 包含预备commit信息的文件名
pre-applypatch	`git am`	虽然这个hook的名称是“打补丁前”，不过实际上的调用时机是打补丁之后、变更commit之前。如果以非0的状态退出，会导致变更成为uncommitted状态。可用于在实际进行commit之前检查代码树的状态。	无
post-applypatch	`git am`	本hook的调用时机是打补丁后、commit完成提交后。因此，本hook无法用于取消进程，而主要用于通知。	无
pre-commit	`git commit`	本hook的调用时机是在获取commit message之前。如果以非0的状态退出则会取消本次commit。主要用于检查commit本身（而不是message）	无
prepare-commit-msg	`git commit`	本hook的调用时机是在接收默认commit message之后、启动commit message编辑器之前。非0的返回结果会取消本次commit。本hook可用于强制应用指定的commit message。	1. 包含commit message的文件名。2. commit message的源（message、template、merge、squash或commit）。3. commit的SHA-1（在现有commit上操作的情况）。
commit-msg	`git commit`	可用于在message提交之后修改message的内容或打回message不合格的commit。非0的返回结果会取消本次commit。	(1) 包含message内容的文件名。
post-commit	`git commit`	本hook在commit完成之后调用，因此无法用于打回commit。主要用于通知。	无
pre-rebase	`git rebase`	在执行rebase的时候调用，可用于中断不想要的rebase。	1. 本次fork的上游。2. 被rebase的分支（如果rebase的是当前分支则没有此参数）
post-checkout	`git checkout` 和 `git clone`	更新工作树后调用checkout时调用，或者执行 git clone后调用。主要用于验证环境、显示变更、配置环境。	1. 之前的HEAD的ref。 2. 新HEAD的ref。 3. 一个标签，表示其是一次branch checkout还是file checkout。
post-merge	`git merge` 或 `git pull`	合并后调用，无法用于取消合并。可用于进行权限操作等git无法执行的动作。	(1) 一个标签，表示是否是一次标注为squash的merge。
pre-push	`git push`	在往远程push之前调用。本hook除了携带参数之外，还同时给stdin输入了如下信息：” ”（每项之间有空格）。这些信息可以用来做一些检查，比如说，如果本地（local）sha1为40个零，则本次push是一个删除操作；如果远程（remote）sha1是40个零，则是一个新的分支。非0的返回结果会取消本次push。	1. 远程目标的名称。 2. 远程目标的位置。
pre-receive	远程repo进行`git-receive-pack`	本hook在远程repo更新刚被push的ref之前调用。非0的返回结果会中断本次进程。本hook虽然不携带参数，但是会给stdin输入如下信息：” ”。	无
update	远程repo进行`git-receive-pack`	本hook在远程repo每一次ref被push的时候调用（而不是每一次push）。可以用于满足“所有的commit只能快进”这样的需求。