在團隊中使用GitLab中的Merge Request工做模式

在工做中使用Git已有5年多的時間了，Git分佈式的工做機制以及強大的分支功能使得在團隊中推廣使用沒有受到什麼阻礙。一直以來都是採用的分支管理模式，我把項目的開發分爲三個階段：開發、測試和上線。

1、分支管理模式

一、開發階段

1. 除了master分支建立一個供全部開發人員開發的dev分支；

    

2. 開發人員在dev分支上進行工做，隨時隨地commit，天天push一次到服務器；

3. push代碼前須要進行pull操做，由於有可能在以前有別的成員先進行了push操做，若是有衝突還須要進行衝突解決；

4. 天天上班後全部成員對dev進行pull操做，獲取全部成員push的代碼，有衝突須要解決；

5. 團隊Leader天天將dev合併一次到master。

二、測試階段

1. 測試進入後就須要添加test分支；

2. 在開發人員將代碼push到dev分支後，能夠在dev基礎上建立test分支，測試人員以test分支搭建測試環境，開始測試；

3. 開發人員在接受到bug後，直接在測試分支上修改，而後讓測試人員進行驗證；

4. 天天團隊Leader將測試分支上修改的bug合併到dev分支上，這樣全部團隊成員當天修復的bug都會在次日被團隊其餘人pull下來；

5. 團隊Leader天天將dev合併一次到master。

三、上線階段

1. 系統上線後試運行階段會存在兩種改動：bug和優化需求，bug一般當天解決晚上部署，優化需求一般週末部署；

2. bug當天能修復的就直接在test分支上修復，而後進行測試，驗證經過後合併到master；

3. bug當天不能修復的就針對該bug建立一個分支，修復完後合併到test分支進行測試，驗證經過後合併到master；

4. 每一個優化需求都以master分支爲基礎建立一個feature分支，完成後合併到dev分支，開發人員能夠先交叉測試，而後將dev合併到test進行測試，驗證經過後合併到master；

5. master始終是一個乾淨的，可發佈的分支。

2、Merge Request模式

一直以來，都以爲Merge Request模式高不可攀，只有作開源軟件纔會採用這種模式，沒想到這麼快就已經在團隊中開始推行使用了，先看一張圖來了解下Merge Request的開發流程：

1. 需求或是Bug都是用Issue來表示；

    

2. 雖然Issue不支持多層級，但結合里程碑、標籤等仍是能夠很好的對任務和Bug進行管理；

3. 管理員和團隊成員均可以進行Issue的建立；

4. 任務的接收者對Issue建立Merge Request；

5. 完成任務後推送代碼到Merge Request對應的分支；

6. 管理員對代碼進行Merge。

相比較傳統的分支管理模式，Merge Request能夠給咱們帶來下面幾個好處：

1. 重要分支設置爲受保護，杜絕了有些問題代碼被提交了，但項目經理不知道的狀況；

    

2. 每一個任務都有一個對應的分支，互相隔離，全部的代碼改動有據可查；

3. 開發人員不用在分支間切換和合並，更專一於開發。

下面以一個示例來介紹Merge Request的工做流程

一、設置重要分支受保護

在上圖中的位置能夠將全部的重要分支設置爲受保護，重要的分支一般是master、release、test等。

二、建立Issue

任務建立後，開發人員就能夠對該任務建立Merge Request了，以下圖：

• 建立Merge Request時會建立針對這個任務對一個分支；
• 分支名稱的格式爲：任務編號-[任務標題中出現的英文和數字]，固然分支名稱也能夠自行修改；
• 分支的Source爲該項目設置的主分支，主分支能夠在設置/General/General project settings/Default Branch進行設置。

三、使用你熟悉的工具拉取Merge Request對應的分支到本地進行代碼修改，修改完成後，Push代碼到服務器，代碼推送後，管理員在Merge Request頁面能夠看到Merge按鈕，以下圖：

點擊右邊的Resole WIP status後，Merge按鈕就可使用

若是勾選Remove source brance，當Merge後，服務器端會刪除建立的分支。Merge完成，會關閉關聯的任務，但並非每一次推送均可以很是順利，有時會有衝突，當本地代碼和服務器代碼不一致時，會出現解決衝突的按鈕，解決衝突後才能進行Merge

代碼Merge後，開發人員就能夠按照一樣的流程作下一個任務了。

3、思考

• 若是系統上線後有緊急Bug須要處理，這個流程應該怎樣去調整？
• 每一個任務都在單獨分支並行開發，這是若是A和B都以來C開發的一個模塊，應該怎麼解決？
• 理論上Issue管理員和開發人員均可以進行建立，什麼樣的Issue能夠有開發人員來建立？

4、總結

• 任何一種模式或工做方式的改變，總會打破一些人的溫馨區，咱們應該學會走出溫馨區，擁抱變化；
• 嘗試新的東西確定會遇到各類問題，先執行，而後再持續優化改進，逐步達到最優狀態；
• 從團隊試用的狀況來看，暫時沒有出現水土不服的狀況。

原文出處：fwhyy -> http://www.fwhyy.com/2018/06/Use-the-Merge-Request-working-mode-in-GitLab-in-the-team/