Git Hooks簡介

本文由作者@PengEdy將其發表在Segmentfault上的兩篇文章聯合修訂而成。

原文鏈接：http://page.renren.com/601846477/channel-noteshow-918871212

什么是Git Hooks？

話說，如同其他許多的版本控制系統一樣，Git也具有在特定事件發生之前或之后執行特定腳本代碼功能（從概念上類比，就與監聽事件、觸發器之類的東西類似）。Git Hooks就是那些在Git執行特定事件（如commit、push、receive等）后觸發運行的腳本。

按照Git Hooks腳本所在的位置可以分為兩類：

• 本地Hooks，觸發事件如commit、merge等。
• 服務端Hooks，觸發事件如receive等。

Git Hooks能做什么？

Git Hooks是定制化的腳本程序，所以它實現的功能與相應的git動作相關；在實際工作中，Git Hooks還是相對比較萬能的。下面僅舉幾個簡單的例子：

• pre-commit: 檢查每次的commit message是否有拼寫錯誤，或是否符合某種規范。
• pre-receive: 統一上傳到遠程庫的代碼的編碼。
• post-receive: 每當有新的提交的時候就通知項目成員（可以使用Email或SMS等方式）。
• post-receive: 把代碼推送到生產環境。（這就是我想要做的）
• etc...

更多的功能可以按照生產環境的需求寫出來。

Git Hooks是如何工作的？

每一個Git repo下都包含有.git/hoooks這個目錄（沒錯，本地和遠程都是這樣），這里面就是放置Hooks的地方。你可以在這個目錄下自由定制Hooks的功能，當觸發一些Git行為時，相應地Hooks將被執行。

這里是一個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

圖中是我一個本地repo的git hooks示例。

如何開始使用Git Hooks？

好了，前面啰嗦一大堆，這里才是重點。

如圖中所示的文件，是由本地執行的腳本語言寫成的，盡管這些文件默認會是Shell Script，你完全可以給它替換成自己喜歡的Ruby，Python或者Perl。

舉個例子，它是這個樣子的：

關於這些腳本文件的命名，細心的讀者就會發現圖中的文件都是上面Git行為列表中列出的名稱加上后綴.sample。沒錯就是這樣，把那些文件的后綴去掉，或者以列表中的名字直接命名，就會把該腳本綁定到特定的Git行為上。

所以說，Git Hooks的正確操作方式是：寫腳本。

Git Hooks腳本分類

Git Hooks腳本可以按照運行環境分為兩類：本地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作用幾乎一樣。沒錯，默認情況下該腳本是這樣寫的：

也就是說，該腳本會調用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方返回一個錯誤