利用Git鈎子實現代碼發布
1、什么是git鈎子
和其它版本控制系統一樣，
Git能在特定的重要動作發生時觸發自定義腳本。 有兩組這樣的鈎子：客戶端的和服務器端的。客戶端鈎子由諸如提交和合並這樣的操作所調用，而服務器端鈎子作用於諸如接收被推送的提交這樣的聯網操作。
2、安裝一個鈎子
鈎子都被存儲在
Git目錄下的hooks子目錄中。 也即絕大部分項目中的.git/hooks。 當你用git init初始化一個新版本庫時，Git默認會在這個目錄中放置一些示例腳本。這些腳本除了本身可以被調用外，它們還透露了被觸發時所傳入的參數。 所有的示例都是shell腳本，其中一些還混雜了Perl代碼，不過，任何正確命名的可執行腳本都可以正常使用——你可以用Ruby或Python，或其它語言編寫它們。 這些示例的名字都是以.sample結尾，如果想啟用它們，得先移除這個后綴。把一個正確命名且可執行的文件放入Git目錄下的hooks子目錄中，即可激活該鈎子腳本。 這樣一來，它就能被Git調用。
3、常用的鈎子腳本類型
3.1 客戶端鈎子
客戶端鈎子分為很多種。 下面把它們分為：提交工作流鈎子、電子郵件工作流鈎子和其它鈎子。
3.1.1 pre-commit
在鍵入提交信息前運行。它用於檢查即將提交的快照，例如，檢查是否有所遺漏，確保測試運行，以及核查代碼。 如果該鈎子以非零值退出，
Git將放棄此次提交，不過你可以用git commit --no-verify來繞過這個環節。你可以利用該鈎子，來檢查代碼風格是否一致（運行類似lint的程序）、尾隨空白字符是否存在（自帶的鈎子就是這么做的），或新方法的文檔是否適當。
3.1.2 prepare-commit-msg
在啟動提交信息編輯器之前，默認信息被創建之后運行。它允許你編輯提交者所看到的默認信息。該鈎子接收一些選項：存有當前提交信息的文件的路徑、提交類型和修補提交的提交的
SHA-1校驗。它對一般的提交來說並沒有什么用；然而對那些會自動產生默認信息的提交，如提交信息模板、合並提交、壓縮提交和修訂提交等非常實用。你可以結合提交模板來使用它，動態地插入信息。
3.1.3 commit-msg
接收一個參數，此參數即上文提到的，存有當前提交信息的臨時文件的路徑。如果該鈎子腳本以非零值退出，
Git將放棄提交，因此，可以用來在提交通過前驗證項目狀態或提交信息。
3.1.4 post-commit
在整個提交過程完成后運行。 它不接收任何參數，但你可以很容易地通過運行
git log -1 HEAD來獲得最后一次的提交信息。該鈎子一般用於通知之類的事情。
3.1.5 電子郵件工作流鈎子
你可以給電子郵件工作流設置三個客戶端鈎子。 它們都是由
git am命令調用的，因此如果你沒有在你的工作流中用到這個命令，可以跳到下一節。如果你需要通過電子郵件接收由git format-patch產生的補丁，這些鈎子也許用得上。
第一個運行的鈎子是applypatch-msg。它接收單個參數：包含請求合並信息的臨時文件的名字。如果腳本返回非零值，Git將放棄該補丁。你可以用該腳本來確保提交信息符合格式，或直接用腳本修正格式錯誤。
下一個在git am運行期間被調用的是pre-applypatch。有些難以理解的是，它正好運行於應用補丁之后，產生提交之前，所以你可以用它在提交前檢查快照。 你可以用這個腳本運行測試或檢查工作區。 如果有什么遺漏，或測試未能通過，腳本會以非零值退出，中斷git am的運行，這樣補丁就不會被提交。
post-applypatch運行於提交產生之后，是在git am運行期間最后被調用的鈎子。你可以用它把結果通知給一個小組或所拉取的補丁的作者。但你沒辦法用它停止打補丁的過程。
3.1.6 其它客戶端鈎子
-
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鈎子會在垃圾回收開始之前被調用，可以用它來提醒你現在要回收垃圾了，或者依情形判斷是否要中斷回收。
3.2 服務器端鈎子
除了客戶端鈎子，作為系統管理員，你還可以使用若干服務器端的鈎子對項目強制執行各種類型的策略。 這些鈎子腳本在推送到服務器之前和之后運行。 推送到服務器前運行的鈎子可以在任何時候以非零值退出，拒絕推送並給客戶端返回錯誤消息，還可以依你所想設置足夠復雜的推送策略。
3.2.1 pre-receive
處理來自客戶端的推送操作時，最先被調用的腳本是
pre-receive。它從標准輸入獲取一系列被推送的引用。如果它以非零值退出，所有的推送內容都不會被接受。 你可以用這個鈎子阻止對引用進行非快進（non-fast-forward）的更新，或者對該推送所修改的所有引用和文件進行訪問控制。
3.2.2 update
update腳本和pre-receive腳本十分類似，不同之處在於它會為每一個准備更新的分支各運行一次。 假如推送者同時向多個分支推送內容，pre-receive只運行一次，相比之下update則會為每一個被推送的分支各運行一次。 它不會從標准輸入讀取內容，而是接受三個參數：引用的名字（分支），推送前的引用指向的內容的SHA-1值，以及用戶准備推送的內容的SHA-1值。 如果update腳本以非零值退出，只有相應的那一個引用會被拒絕；其余的依然會被更新。
3.2.3 post-receive
post-receive掛鈎在整個過程完結以后運行，可以用來更新其他系統服務或者通知用戶。它接受與pre-receive相同的標准輸入數據。它的用途包括給某個郵件列表發信，通知持續集成（continous integration）的服務器，或者更新問題追蹤系統（ticket-tracking system） —— 甚至可以通過分析提交信息來決定某個問題（ticket）是否應該被開啟，修改或者關閉。 該腳本無法終止推送進程，不過客戶端在它結束運行之前將保持連接狀態，所以如果你想做其他操作需謹慎使用它，因為它將耗費你很長的一段時間。
4、利用鈎子實現代碼發布
根據上述鈎子的種類描述，可利用服務器端post-receive鈎子來實現代碼發布，主要包含步驟如下：
4.1 在服務器上創建版本庫
[root@server ~]# mkdir /usr/local/git-workspace
[root@server local]# cd /usr/local/git-workspace
[root@server local]# git init -bare wwwroot.git
[root@server local]# ls wwwroot.git/
branches config description HEAD hooks index info objects refs
此處需要注意：
初始化版本庫使用了git init -bare而不僅僅是git init，bare漢語意思是：裸，裸的。之所以叫裸倉庫是因為這個倉庫只保存git歷史提交的版本信息，而不允許用戶在上面進行各種git操作。意味着初始化的版本庫(暫且稱為bare repository)只會生成一類文件：用於記錄版本庫歷史記錄的.git目錄下面的文件；而不會包含實際項目源文件的拷貝；所以該版本庫不能稱為工作目錄working tree；如果你進入版本目錄，就會發現只有.git目錄下的文件，而沒有其它文件；就是說,這個版本庫里面的文件都是.git目錄下面的文件，把原本在.git目錄里面的文件放在版本庫的根目錄下面；換句話說，不使用--bare選項時，就會生成.git目錄以及其下的版本歷史記錄文件,這些版本歷史記錄文件就存放在.git目錄下；而使用--bare選項時，不再生成.git目錄,而是只生成.git目錄下面的版本歷史記錄文件，這些版本歷史記錄文件也不再存放在.git目錄下面，而是直接存放在版本庫的根目錄下面。用git init初始化的版本庫用戶也可以在該目錄下執行所有git方面的操作。但別的用戶在將更新push上來的時候容易出現沖突。
4.2 創建web目錄
站點使用nginx和php提供服務，web目錄如下
[root@server]$ mkdir -p /home/website/webroot
4.3 本地初始化和克隆版本庫
[root@localhost ~]$ cd /dev-workspace
[root@localhost dev-workspace]$ git init local.git
[root@localhost dev-workspace]$ cd local.git
[root@localhost local.git]$ git clone ssh://root@xxx.xxx/usr/local/git-workspace/wwwroot.git
拉取代碼通過ssh協議，如果沒有做密鑰就直接輸入服務器密碼即可，若不是使用的默認22端口，命令類似：
git clone ssh://root@xxx.xxx:端口號/usr/local/git-workspace/wwwroot.git
4.4 設置鈎子
[root@server ~]# cd /usr/local/git-workspace/wwwroot/hooks/
[root@server hooks]# vim post-receive
#!/bin/bash
git --work-tree=/home/website/webroot checkout -f
--work-tree對應站點文件目錄
4.5 代碼推送，版本庫接收到推送后自動檢出到web目錄
在本地版本庫工作區里開發，然后使用git push指令推送到遠程裸版本庫，鈎子會post-receive自動生效，將文件檢出到--work-tree目錄里，即代碼一經提交就會自動同步到web目錄下。
至此，利用git鈎子實現代碼發布完成。