Git 鉤子

前些天發現了一個巨牛的人工智能學習網站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉到教程。

和其它版本控制系統一樣，Git 能在特定的重要動作發生時觸發自定義腳本。 有兩組這樣的鉤子：客戶端的和服務器端的。 客戶端鉤子由諸如提交和合并這樣的操作所調用，而服務器端鉤子作用于諸如接收被推送的提交這樣的聯網操作。 你可以隨心所欲地運用這些鉤子。

安裝一個鉤子

鉤子都被存儲在 Git 目錄下的?hooks?子目錄中。 也即絕大部分項目中的?.git/hooks?。 當你用?git init初始化一個新版本庫時，Git 默認會在這個目錄中放置一些示例腳本。這些腳本除了本身可以被調用外，它們還透露了被觸發時所傳入的參數。 所有的示例都是 shell 腳本，其中一些還混雜了 Perl 代碼，不過，任何正確命名的可執行腳本都可以正常使用 —— 你可以用 Ruby 或 Python，或其它語言編寫它們。 這些示例的名字都是以?.sample?結尾，如果你想啟用它們，得先移除這個后綴。

把一個正確命名且可執行的文件放入 Git 目錄下的?hooks?子目錄中，即可激活該鉤子腳本。 這樣一來，它就能被 Git 調用。 接下來，我們會講解常用的鉤子腳本類型。

客戶端鉤子

客戶端鉤子分為很多種。 下面把它們分為：提交工作流鉤子、電子郵件工作流鉤子和其它鉤子。

Note	需要注意的是，克隆某個版本庫時，它的客戶端鉤子?并不?隨同復制。 如果需要靠這些腳本來強制維持某種策略，建議你在服務器端實現這一功能。（請參照?使用強制策略的一個例子?中的例子。）

提交工作流鉤子

前四個鉤子涉及提交的過程。

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）是否應該被開啟，修改或者關閉。 該腳本無法終止推送進程，不過客戶端在它結束運行之前將保持連接狀態，所以如果你想做其他操作需謹慎使用它，因為它將耗費你很長的一段時間。

?

轉自：https://git-scm.com/book/zh/v2/%E8%87%AA%E5%AE%9A%E4%B9%89-Git-Git-%E9%92%A9%E5%AD%90