Git分支管理，運維知道嗎？

需求

對於程式碼的管理，不知你是否遇到過以下幾種情況：

• 存在多種版本管理工具，如svn、git，無法做到程式碼統一管理;

• 多人協作開發，程式碼合併衝突頻發;

• 分支管理混亂，存在很多個性化分支;

• 提測程式碼被覆蓋，嚴重影響開發進度;

• 程式碼倉庫多使用者管理及許可權管理混亂;

• 等等

以上情況如果沒有一個統一的程式碼倉庫的管理規範，無論在測試階段還是在生產上線過程中都將會是“一地雞毛”。在此我們選擇開源分散式版本控制系統Git作為程式碼倉庫，並給大家介紹下已在企業生產實踐中經過驗證的Git分支管理規範。

環境介紹

程式碼版本在真正上生產環境前，需要經過一系列環境的測試驗證：

1、開發環境，研發人員本地開發環境用於除錯開發;

2、測試環境，研發人員進行系統聯調測試;

3、封測環境，測試人員進行初步整體驗收測試;

4、準生產環境，類生產環境，用於測試人員進行最終整體驗收測試;

最終要上線的版本只有在經過測試人員的驗收、評審後才可以交付到生產環境。

其中評審環節非常重要，需要測試、開發、運維對以下幾方面做最終的確認：

• 確定Git分支是否合併到Master，保證生產使用Master分支的程式碼;

• 確定本次業務方需求涉及到的系統，以便有問題能夠及時發現是否和本次變更有關;

• 確定上線系統是否在各測試環境驗證透過，對於驗收不透過的版本禁止釋出;

• 確定上線系統發版順序的前後依賴，避免因釋出順序導致的業務流轉不通;

• 確定配置檔案是否提交或更新到配置中心;

• 確定資料庫相關DDL、DML是否需要DBA配合提前執行;

• 確定系統版本號、版本釋出時間及系統相關研發人員;

• 等等其他細節;

經過評審後最終由運維按照版本釋出時間進行上線，上線完成後由業務方進行驗證。

分支型別

為保證Git分支的有序使用，結合各環境的規劃我們定義了以下分支：

1、Master分支

主分支，用於準生產環境釋出，與生產環境保持一致;

2、Hotfix分支

補丁分支，用於生產環境上的版本進行Bug修復;

3、Release分支

釋出分支，用於封測環境的整體驗收測試;

4、Feature分支

功能分支，用於測試環境的功能聯調測試;

其中，本地倉庫並不是Git分支，而是基於遠端Feature分支拉取到本地的開發倉庫，用於開發環境的開發除錯。

分支使用場景

1、功能開發

當有新功能開發時，需要從Master分支clone到Feature分支;

開發人員基於遠端Feature分支拉取到本地的開發倉庫，進行本地開發除錯;

當Bug分支有補丁修復時，需要首先將其合併到遠端Feature分支，然後再合併到本地Feature倉庫;

2、Bug修復

當線上版本有Bug時，需要基於Master分支clone到Hotfix分支;

開發完成後需要將其合併到Master分支，並在準生產環境進行驗收併發布;

驗收發布後需要將程式碼合併到Feature分支，然後再合併到本地Feature倉庫，完成閉環;

3、測試環境釋出

將本地倉庫的程式碼合併至遠端Feature分支;

打包釋出，開發人員聯調測試;

4、封測環境釋出

將Feature分支合併至Release分支;

打包釋出，測試人員初步整體功能聯調測試;

5、準生產環境釋出

將Release分支合併至Master分支;

打包釋出，測試人員最終整體功能驗收測試;

6、標籤管理

Master程式碼驗收透過，需要基於“版本號+日期”打標籤並代表本次變更完成;

7、Master分支鎖定

Master分支只有在發版視窗前才可以提交合並，其他時間鎖定，避免Master分支混亂;

以上場景需要注意的是，需要適時同步下遠端分支的程式碼，否則很容易導致程式碼衝突。

多分支流水線

為保證各環境的系統版本的快速的CI/CD，我們一般會針對系統應用、環境、分支建立多個work，這無疑也會加大配置管理的難度。

因此我們可以使用Jenkins 擴充套件共享庫和多分支流水線的功能，實現一個work對應多個環境、多個分支的需求，這無疑減少了一定的工作量，有興趣的可以參考公眾號內實踐應用《CI/CD流水線》內的文章。