什么是Git Hooks？
話說，如同其他許多的版本控制系統一樣，Git也具有在特定事件發生之前或之后執行特定腳本代碼功能（從概念上類比，就與監聽事件、觸發器之類的東西類似）。
Git Hooks就是那些在Git執行特定事件（如commit、push、receive等）后觸發運行的腳本。
按照Git Hooks腳本所在的位置可以分為兩類：
1.本地Hooks，觸發事件如commit、merge等。
2.服務端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
如何開始使用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方返回一個錯誤
參考鏈接http://page.renren.com/601846477/channel-noteshow-918871212
