瞭解Git的Hook機制
gitLab hooks大體上分爲兩類：客戶端鉤子和服務器端鉤子,如下 先從一張圖瞭解一下Hooks的階段
1.1： 客戶端鉤子
pre-commit
鉤子在鍵入提交信息前運行。 它用於檢查即將提交的快照，例如，檢查是否有所遺漏，確保測試運行，以及覈查代碼。 如果該鉤子以非零值退出，Git 將放棄此次提交，不過你可以用 git commit --no-verify 來繞過這個環節。 你可以利用該鉤子，來檢查代碼風格是否一致（運行類似 lint 的程序）、尾隨空白字符是否存在（自帶的鉤子就是這麼做的），或新方法的文檔是否適當。prepare-commit-msg
鉤子在啓動提交信息編輯器之前，默認信息被創建之後運行。 它允許你編輯提交者所看到的默認信息。 該鉤子接收一些選項：存有當前提交信息的文件的路徑、提交類型和修補提交的提交的 SHA-1 校驗。 它對一般的提交來說並沒有什麼用；然而對那些會自動產生默認信息的提交，如提交信息模板、合併提交、壓縮提交和修訂提交等非常實用。 你可以結合提交模板來使用它，動態地插入信息。
commit-msg
鉤子接收一個參數，此參數即上文提到的，存有當前提交信息的臨時文件的路徑。 如果該鉤子腳本以非零值退出，Git 將放棄提交，因此，可以用來在提交通過前驗證項目狀態或提交信息。 在本章的最後一節，我們將展示如何使用該鉤子來覈對提交信息是否遵循指定的模板。
post-commit
鉤子在整個提交過程完成後運行。 它不接收任何參數，但你可以很容易地通過運行 git log -1 HEAD 來獲得最後一次的提交信息。 該鉤子一般用於通知之類的事情。
post-applypatch
運行於提交產生之後，是在 git am 運行期間最後被調用的鉤子。 你可以用它把結果通知給一個小組或所拉取的補丁的作者。 但你沒辦法用它停止打補丁的過程。
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 鉤子會在垃圾回收開始之前被調用，可以用它來提醒你現在要回收垃圾了，或者依情形判斷是否要中斷回收。
1.2: 服務器端鉤子
pre-receive
處理來自客戶端的推送操作時，最先被調用的腳本是 pre-receive。 它從標準輸入獲取一系列被推送的引用。如果它以非零值退出，所有的推送內容都不會被接受。 你可以用這個鉤子阻止對引用進行非快進（non-fast-forward）的更新，或者對該推送所修改的所有引用和文件進行訪問控制。
update
update 腳本和 pre-receive 腳本十分類似，不同之處在於它會爲每一個準備更新的分支各運行一次。 假如推送者同時向多個分支推送內容，pre-receive 只運行一次，相比之下 update 則會爲每一個被推送的分支各運行一次。 它不會從標準輸入讀取內容，而是接受三個參數：引用的名字（分支），推送前的引用指向的內容的 SHA-1 值，以及用戶準備推送的內容的 SHA-1 值。 如果 update 腳本以非零值退出，只有相應的那一個引用會被拒絕；其餘的依然會被更新。
post-receive
post-receive 掛鉤在整個過程完結以後運行，可以用來更新其他系統服務或者通知用戶。 它接受與 pre-receive 相同的標準輸入數據。 它的用途包括給某個郵件列表發信，通知持續集成（continous integration）的服務器， 或者更新問題追蹤系統（ticket-tracking system） —— 甚至可以通過分析提交信息來決定某個問題（ticket）是否應該被開啓，修改或者關閉。 該腳本無法終止推送進程，不過客戶端在它結束運行之前將保持連接狀態， 所以如果你想做其他操作需謹慎使用它，因爲它將耗費你很長的一段時間。
2: 如何使用Hooks
2.1：客戶端Hooks使用
1：項目的hooks如下,地址爲當前項目的.git/hooks目錄下
ps：只有去掉.sample後綴才能生效,並且不能全局配置 只能在配置的項中生效
2：開始一個簡單的Demo-檢查commit信息的長度不能小於10
ps：在.git/hooks目錄下找到commit-msg.sample，重命名爲commit-msg,腳本如下
#!/bin/sh
MSG=`awk '{printf("%s",$0)}' $1`
if [ ${#MSG} -lt 10 ]
then
echo "-------------------------------------------------------------------"
echo "commit message 只有${#MSG}字符"
echo "message的長度不能小於10, 本次提交失敗，請完善commit message，再提交"
echo "-------------------------------------------------------------------"
exit 1
fi
>>執行效果如下 客戶端的hooks一般會在push到服務端之前就觸發相關操作
2.2：服務端Hooks使用
1：修改配置，並創建一個pre-recevie勾子
# 1: 創建custom_hooks_dir文件夾(目錄任意)並創建pre-receive.d,update.d,post-receive.d三個文件
mkdir -p /opt/gitlab/custom_hooks/{pre-receive.d,update.d,post-receive.d}
# 2:修改文件的執行權限
chown +x /opt/gitlab/custom_hooks/
# 3: 創建pre-recevie文件並賦予可執行權限
cd /opt/gitlab/custom_hooks/pre-receive.d
touch pre-recevie
chmod 777 pre-recevie
# 4: 執行gitlab reconfigure
sudo gitlab-ctl reconfigure 2：執行一個簡單的demo-提交成功後輸出一段文本
ps：如下腳本 提交成功後輸出一段文本
#!/bin/bash
echo "您已經提交成功了"
ps：執行結果如下；我們可以發現跟2.1相比客戶端hooks與服務端hooks可以有同樣的功能 但是執行的階段是不一樣的
3: [探討]GitLab的Hooks可以做些什麼
1：結合自身在工作中的實踐我認爲可以做這些事情
1：代碼提交的Commit Message規則檢查
2：版本命名規則檢查
3：代碼基本的規範檢查（例如：檢查一下注釋、代碼中是否有備註author等信息）
4：代碼的質量檢查（可以結合SonrQube做代碼的質量檢查，從源頭防止一些不健康的代碼被提交到代碼倉庫）
5：測試環境的自動化部署（當然這個Jenkins結合git的webhooks也可以做到）