如何在內部 Stash 服務器上添加 hook

關於 hook

所謂的 hook 就是存在於.git/hooks/ 目錄下的一些腳本文件（shell、Python、Ruby、Perl 皆可），這些腳本文件能夠在某些 git 操做執行以前或者以後觸發，可讓開發者來自定義屬於本身的工做流。好比咱們能夠在本身本地添加一個 hook 在咱們每次提交 commit 信息之後執行，檢查咱們的 commit 信息是否符合規範，若是不規範就退出當前此次提交。git 爲咱們預留了 14 個 hook 分別適用於本地 commit 、郵件通知、衍合、合併、開新分支以及服務器接收提交。在使用的時候只要把咱們寫好的腳本按照 git 要求的文件名放到 git 倉庫中的 .git/hooks/目錄中就好。

如何在 Stash 中添加 hook

若是想添加服務器 hook，就須要在服務器端的 .git/hooks/目錄下添加腳本文件，這就須要擁有 Stash 服務器的文件系統的權限，若是是在公司的環境下還要去向管理員申請權限，是比較麻煩的，還好目前 Stash 上有一些插件能夠比較方便的實現咱們通常在服務器添加 hook 要實現的需求，這裏挑兩個簡單介紹下。

Yet Another Commit Checker

這個插件主要用於檢查 commit message ，其是一個 pre-receive hook ，就是說若是 commit message 若是不合法，這些 commit 就會沒法 push 上去。該插件的主要功能有：

• 檢查 commit 的郵箱、姓名；

• 利用正則表達式檢查 commit message；

• 經過 JIRA 檢查 commit message 中的 task ID 是否合法，同時會忽略一些相似 task ID 的字段（好比『UTF-8』這種的）；

• 經過 JQL規定查找到的 task 的狀態，好比能夠規定 task ID 對應的 task 必須狀態是 Open 的；

• 經過正則檢查分支名；

• 自定義錯誤提示消息；（默認的錯誤消息裏頭有一隻萌萌的小熊）

• 忽略 merge 的 commit 不進行檢查，也能夠經過正則忽略一些 commit 不進行檢查， 也能夠忽略從其餘 service 來的 commit （如 CI 系統的生成的 commit）。

使用配置

在 Stash 中安裝插件後，點擊插件後就能夠打開插件的配置項。配置項分爲不少部分，如下一一陳述。

首先是配置 commit message 的檢查選項，前兩項開啓後會檢查 push 的 commit message 中是否使用的是 Stash 上的用戶名和郵箱。第三項則是自定義的用於檢查 commit message 的正則表達式,這裏要求整個 commit message 都要符合這個正則表達式。這裏寫的是([A-Z]+-\d+)-(.|\n)*，最後的(.|\n)*是爲了識別多行的 commit message。

而後是配置是否檢查 task ID 合法。前面的正則表達式僅僅可以檢查格式上是否符合一個 task ID 的格式，可是會把『IPH-456-test』這樣的內容認爲是合法的，要想作進一步的檢查，就須要向 JIRA 查詢這個 task ID 是不是合法的。

開啓了第一個選項之後，若是以前的正則表達式的部分沒有分組，那麼就會用全部的 commit message 做爲 task ID 去進行合法性校驗（首先 commit message 要符合正則）。若是正則表達式有分組，就會用符合正則表達式的部分中對應分組的部分做爲 task ID 去進行合法性校驗。能夠用第二種方式來主動定位 task ID。（若是有多個分組呢？測試後發現有多個分組時會把第一個分組做爲 task ID）。

第二個選項則是會忽略一些形似 task ID 的、符合正則的 commit message 部分，好比『UTF-8』這樣的部分。開啓了第二個選項能夠防止由於這樣的字符存在而致使的檢查失敗。

第三個選項是使用 JQL 來設置查找到的 task 的狀態，好比能夠經過 status="open"來指定對應的 task 必須是處於 open 狀態的。更多的一些用法能夠參照 JQL 的語法。

而後還能夠利用正則表達式檢查分支名。

自定義錯誤信息，這樣 push 失敗之後就會這樣顯示（小熊是默認的 header）：

最後就是設置例外 commit 了，第一個選項開啓後能夠提交 merge commit ，第二個就是用正則來進行例外設置，第三個開啓後則是會例外一些來自服務的 commit。