## Git 鉤子 和其它版本控制系統一樣，Git 能在特定的重要動作發生時觸發自定義腳本。 有兩組這樣的鉤子：客戶端的和服務器端的。 客戶端鉤子由諸如提交和合并這樣的操作所調用，而服務器端鉤子作用于諸如接收被推送的提交這樣的聯網操作。 你可以隨心所欲地運用這些鉤子。 ## 安裝一個鉤子 鉤子都被存儲在 Git 目錄下的?`hooks`?子目錄中。 也即絕大部分項目中的?`.git/hooks`?。 當你用?`git init`?初始化一個新版本庫時，Git 默認會在這個目錄中放置一些示例腳本。這些腳本除了本身可以被調用外，它們還透露了被觸發時所傳入的參數。 所有的示例都是 shell 腳本，其中一些還混雜了 Perl 代碼，不過，任何正確命名的可執行腳本都可以正常使用 —— 你可以用 Ruby 或 Python，或其它語言編寫它們。 這些示例的名字都是以?`.sample`?結尾，如果你想啟用它們，得先移除這個后綴。 把一個正確命名且可執行的文件放入 Git 目錄下的?`hooks`?子目錄中，即可激活該鉤子腳本。 這樣一來，它就能被 Git 調用。 接下來，我們會講解常用的鉤子腳本類型。 ## 客戶端鉤子 客戶端鉤子分為很多種。 下面把它們分為：提交工作流鉤子、電子郵件工作流鉤子和其它鉤子。 > ###### NOTE > 需要注意的是，克隆某個版本庫時，它的客戶端鉤子?**并不**?隨同復制。 如果需要靠這些腳本來強制維持某種策略，建議你在服務器端實現這一功能。（請參照?[使用強制策略的一個例子](http://git-scm.com/book/zh/v2/ch00/_an_example_git_enforced_policy)中的例子。） #### 提交工作流鉤子 前四個鉤子涉及提交的過程。 `pre-commit`?鉤子在鍵入提交信息前運行。 它用于檢查即將提交的快照，例如，檢查是否有所遺漏，確保測試運行，以及核查代碼。 如果該鉤子以非零值退出，Git 將放棄此次提交，不過你可以用`git commit --no-verify`?來繞過這個環節。 你可以利用該鉤子，來檢查代碼風格是否一致（運行類似?`lint`?的程序）、尾隨空白字符是否存在（自帶的鉤子就是這么做的），或新方法的文檔是否適當。 `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`?鉤子運行于變基之前，以非零值退出可以中止變基的過程。 你可以使用這個鉤子來禁止對已經推送的提交變基。 Git 自帶的?`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）是否應該被開啟，修改或者關閉。 該腳本無法終止推送進程，不過客戶端在它結束運行之前將保持連接狀態，所以如果你想做其他操作需謹慎使用它，因為它將耗費你很長的一段時間。