Svn Git hooks scripts

簡介

      SVN全名Subversion，是一款集中式的程式碼版本控制系統，早期Linux/eCos開發時如果對多人協同的要求不是很高的話，使用的是這個管理軟體還是比較方便的。

Git 是一款分散式版本控制系統（Distributed Version Control System，簡稱 DVCS ）。Android的出現擴大Git的使用範圍，由於Android預設就是需要多人協同，原有的集中式的版本管理系統已經不能滿足需求，所以Android的開發團隊選擇使用Git進行程式碼的管理。

Svn hook scripts

       關於hook scripts的詳細說明可以參考客戶端（TortoiseSVN）的幫助文件，這裡只做簡單的介紹。

服務端的掛鉤指令碼(hook scripts)

     Hookscripts(掛鉤指令碼)是在程式碼版本發生變化時所觸發的程式，比如在建立一個新的程式碼版本或者修改版本控制的屬性。每個掛鉤(hook)都能拿到足夠的資訊標明觸發掛鉤(hook)的是什麼事件，執行的目標平臺，和觸發掛鉤的使用者名稱稱等。Svn的客戶端可以根據掛鉤程式的輸出或者返回值決定下一步的該做什麼（可以停止、繼續、暫停使用者的行為）。

       掛鉤指令碼會被管理程式碼倉庫的伺服器執行，當然客戶端（TortoiseSVN）也允許配置掛鉤指令碼，然後再特定的事件下觸發指令碼。

       程式碼倉庫的hooks目錄下可以找到掛鉤指令碼的範例。這些範例指令碼可以在Unix/Linux平臺的伺服器上執行，但是如果使用的使用windows 伺服器的話需要做一些修改。Windows下的掛鉤可以是一個批處理檔案(.bat)或者可執行檔案(.exe).下面給出一個可以在windows伺服器上執行的掛鉤指令碼。

rem Only allow log messages to be changed.
if "%4" == "svn:log" exit 0
echo Property '%4' cannot be changed >&2
exit 1

注意事項：如果你想要在你的螢幕上顯示掛鉤指令碼中的列印資訊，你就必須交列印資訊輸出到stderr。

客戶端掛鉤指令碼（hook scripts）

       你可以在客戶端設定掛鉤指令碼，一旦配置成功，那麼指令碼就會在特定的事件下被觸發，與伺服器端的指令碼不同，客戶端的指令碼是在客戶端本地執行的。

       一個應用程式可能希望在提交程式碼之後通過掛鉤指令碼重新編譯程式碼或者更新版本號都是可以的。

       如下如所示，你可以在客戶端指定指令碼以及程式碼工作目錄的用於特定程式碼塊觸發掛鉤指令碼。預設請款下客戶端沒有任何的hook scripts，需要通過圖2.2-1所示新增指令碼，一共有6中指令碼型別可供選擇：

• Start-commit

在提交程式碼的對話框出現之前被呼叫。

• Pre-commit

在點選OK提交程式碼的時候被呼叫，此行為會在commit程式碼到伺服器之前被呼叫，所以你可以使用此指令碼檢查commit log或者修改的程式碼是否符合規範。

• Post-commit

在程式碼提交到伺服器之前被呼叫，通常可以用來提示使用者提交程式碼是成功還是失敗。

• Start-update

在 update-to-revision 對話方塊顯示之前被呼叫。

• Pre-update

在“update”命令實際執行之前被呼叫。

• Post-update

在“update”命令執行完成後被呼叫，主要用於提示“update”是否成功。

圖 2.2-1

圖2.2-2

Git hook scripts（掛鉤指令碼）

      和其他版本控制系統一樣，當某些重要事件發生時，Git 以呼叫自定義指令碼。有兩組掛鉤：客戶端和伺服器端。客戶端掛鉤用於客戶端的操作，如提交和合並。伺服器端掛鉤用於Git 伺服器端的操作，如接收被推送的提交。你可以隨意地使用這些掛鉤，下面會講解其中一些。

安裝一個掛鉤

      掛鉤都被儲存在 Git 目錄下的hooks子目錄中，即大部分專案中的.git/hooks。 Git 預設會放置一些指令碼樣本在這個目錄中，除了可以作為掛鉤使用，這些樣本本身是可以獨立使用的。所有的樣本都是shell指令碼，其中一些還包含了Perl的指令碼，不過，任何正確命名的可執行指令碼都可以正常使用 — 可以用Ruby或Python，或其他。在Git 1.6版本之後，這些樣本名都是以.sample結尾，因此，你必須重新命名。在Git 1.6版本之前，這些樣本名都是正確的，但這些樣本不是可執行檔案。把一個正確命名且可執行的檔案放入 Git 目錄下的hooks子目錄中，就可以啟用該掛鉤指令碼，因此，之後他一直會被Git 呼叫。隨後會講解主要的掛鉤指令碼。

客戶端掛鉤

      有許多客戶端掛鉤，以下把他們分為：提交工作流掛鉤、電子郵件工作流掛鉤及其他客戶端掛鉤。

• 提交工作流掛鉤

有 4個掛鉤被用來處理提交的過程：

pre-commit掛鉤在鍵入提交資訊前執行，被用來檢查即將提交的快照，例如，檢查是否有東西被遺漏，確認測試是否執行，以及檢查程式碼。當從

該掛鉤返回非零值時，Git 放棄此次提交，但可以用git commit --no-verify來忽略。該掛鉤可以被用來檢查程式碼錯誤（執行類似lint的程式），檢查尾部空白（預設掛鉤是這麼做

的），檢查新方法（譯註：程式的函式）的說明。

prepare-commit-msg掛鉤在提交資訊編輯器顯示之前，預設資訊被建立之後執行。因此，可以有機會在提交作者看到預設資訊前進行編輯。該掛鉤接收一些選項：擁有提交資訊的檔案路徑，提交型別，如果是一次修訂的話，提交的SHA-1校驗和。該掛鉤對通常的提交來說不是很有用，只在自動產生的預設提交資訊的情況下有作用，如提交資訊模板、合併、壓縮和修訂提交等。可以和提交模板配合使用，以程式設計的方式插入資訊。

commit-msg掛鉤接收一個引數，此引數是包含最近提交資訊的臨時檔案的路徑。如果該掛鉤指令碼以非零退出，Git 放棄提交，因此，可以用來在提交通過前驗證專案狀態或提交資訊。本章上一小節已經展示了使用該掛鉤核對提交資訊是否符合特定的模式。

post-commit掛鉤在整個提交過程完成後執行，他不會接收任何引數，但可以執行git log-1 HEAD來獲得最後的提交資訊。總之，該掛鉤是作為通知之類使用的。

      提交工作流的客戶端掛鉤指令碼可以在任何工作流中使用，他們經常被用來實施某些策略，但值得注意的是，這些指令碼在clone期間不會被傳送。可以在伺服器端實施策略來拒絕不符合某些策略的推送，但這完全取決於開發者在客戶端使用這些指令碼的情況。所以，這些指令碼對開發者是有用的，由他們自己設定和維護，而且在任何時候都可以覆蓋或修改這些指令碼。

伺服器端掛鉤

      除了客戶端掛鉤，作為系統管理員，你還可以使用兩個伺服器端的掛鉤對專案實施各種型別的策略。這些掛鉤指令碼可以在提交物件推送到伺服器前被呼叫，也可以在推送到伺服器後被呼叫。推送到伺服器前呼叫的掛鉤可以在任何時候以非零退出，拒絕推送，返回錯誤訊息給客戶端，還可以如你所願設定足夠複雜的推送策略。

pre-receive 和 post-receive

處理來自客戶端的推送（push）操作時最先執行的指令碼就是pre-receive 。它從標準輸入（stdin）獲取被推送引用的列表；如果它退出時的返回值不是0，所有推送內容都不會被

接受。利用此掛鉤指令碼可以實現類似保證最新的索引中不包含非fast-forward型別的這類效果；抑或檢查執行推送操作的使用者擁有建立，刪除或者推送的許可權或者他是否對將要修改的每一個檔案都有訪問許可權。

post-receive 掛鉤在整個過程完結以後執行，可以用來更新其他系統服務或者通知使用者。它接受與pre-receive相同的標準輸入資料。應用例項包括給某郵件列表發信，通知

實時整合資料的伺服器，或者更新軟體專案的問題追蹤系統 —— 甚至可以通過分析提交資訊來決定某個問題是否應該被開啟，修改或者關閉。該指令碼無法組織推送程序，不過客戶端在它完成執行之前將保持連線狀態；所以在用它作一些消耗時間的操作之前請三思。