之前寫過實踐應用一，內容比較入門，基本使用情況和大家一樣，作爲一個管理代碼的工具。今天這篇屬於高級篇，結合我們使用的情況重點介紹下git和gitlab的擴展應用。
git 鉤子
我碰到個場景，需要在代碼merge之前，就判斷出代碼或者相關的內容合不合規，而gitlab的CI事件都是後置觸發。即使判斷有問題，動作提交發生了，如果rd沒有等到後置判斷的結果，而又去處理其他事情了。當有問題的時候，再去修改。整個過程時間比較長，不如在用戶提交的時候就去做些判斷，經過對比調研。感覺git鉤子比較適合。
git鉤子安裝
關於git鉤子的介紹，這裏簡單說下，git鉤子的代碼是在本地的，不在代碼庫中。地址一般在你項目的 .git/hooks/ 裏面，如下圖，可以看到很多的文件，對應git不同的動作，選擇一個去掉結尾的 .sample 就可以了。
場景實現
還需要考慮一點，怎麼能讓所有人都強制安裝上，成爲開發的必須一步。此時，注意到我們的項目代碼使用了php composer，即：某些公共模塊寫成了 composer 包的形式，放在內部私有庫上。部署開發環境，需要執行一步。我們也採取同樣的方式，寫成了一個 composer 包的形式。然後在composer的腳本中，做處理。結合我們的項目特點如下流程：
相關步驟：
一. 開發 php composer 擴展包。
二. 基於我們現實的情況，項目初次需要執行composer install/update。這樣我們就把第一步的包加載引入到了項目裏面。
三. 在 composer 的腳本里面加入執行語句，執行一個腳本。腳本主要實現檢測 git 鉤子對應的內容是否存在，文件同第一步的文件比較是否是最新的。
腳本位置可參考composer.json如下內容：
"scripts": {
"post-install-cmd": [
"@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""],
"post-update-cmd": [
"@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""],
"post-package-install": [
"@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""],
"post-package-update": [
"@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""]
},四. 如果第三部中檢測到沒有安裝，或者不是最新的。則進行拷貝，更改文件的權限爲可以執行。
執行的效果
當以上步驟都執行後，我們就可以實際使用了，當然，我這裏只用到了 post-checkout（開發初期，切換分支提示去幹某些事）和 commit-msg腳本 (提交代碼標籤檢測，提交信息檢測)。
當需求新建立時，一般會 git branch xxx && git check xxx，然後 post-checkout 腳本就被觸發了，提示你去幹什麼事。
2. 代碼功能完成，提交時進行一些檢測。
以上，有興趣的同學可以深入探討。
gitlab issue
業界有很多專業的管理需求的軟件，公司內部也有jira等工具，但結合友軍和業務實際情況考慮。我們採用gitlab issue進行做需求跟蹤。先說下背景：業務方多，平時需求對接各式各樣，QQ，微信，最好的發送個郵件。業務跟蹤困難。單項業務週期短，而考察了幾個兄弟部門的情況和網上的介紹，整齊劃一選擇issue作爲項目需求管理的工具。
gitlab onboard
這裏不得不說 gitlab 的看板功能，這個做簡單項目跟蹤一目瞭然。業界包括很多著名的公司，都用看板功能去跟蹤需求進度。我看了某些著名保險公司的團隊項目管理的視頻，有些團隊真的準備了一塊白板，然後通過貼紙條的形式，完成看板功能。然後每天開晨會的形式去跟進狀態。
默認的欄目可以分成如下幾種：
Doing => To Do => Closed
當然，你也可以根據實際需要，按照你的定義分類。然後給每個issue貼上對應的標籤，就可以反映出狀態了，如下圖是我們的線上實際情況展示。
Webhooks
我這裏還有一個玩法：Webhooks，我們來看官方的介紹：
Webhooks can be used for binding events when something is happening within the project.
應用場景：怎麼知道你的issue建立的對不對，格式有沒有問題。當狀態更新的時候能不能做些什麼。代碼merge request的時候，是否需要做些聯動等等。以下是我們的使用情況：
gitlab CI
和業界小夥伴使用方法一樣，我們這裏主要體現在幾個方面：
1. 提交代碼之後，觸發CI的規則，在裏面做些檢測，如：相關代碼規範，單元測試等。
2. 結合jenkins做持續集成。在項目的gitlab CI對應的配置文件裏面對應的規則和對接jenkins的接口，這樣當你對代碼做某種操作，如打符合既定特徵的tag的時候，就可以觸發jenkins任務了，在jenkins裏可以進行構建鏡像，代碼上線等內容。
以上，僅是我站在個人的角度，對接觸到的git和gitlab的一些總結，過程的探索了離不開大家基於自身項目的狀況進行的不斷嘗試。如果大家有什麼想了解的更細緻的，請聯繫我。