Git分支管理規範

關於Git的一些分支管理規範。。。

 

1、分支與角色說明

Git 分支類型

master 分支（主分支） 穩定版本

develop 分支（開發分支） 最新版本

release 分支（發佈分支） 發佈新版本

hotfix 分支（熱修復分支） 修復線上Bug

feature 分支（特性分支） 實現新特性

Gitlab 角色與項目角色對應關係

Owner（擁有者） Git 管理員

Master（管理員） 開發主管

Developer（開發者） 開發人員

Reporter（報告者） 測試人員

Guest（觀察者） 其餘人員

 

2、分支簡明使用流程

一、每開發一個新功能，建立一個 feature 分支，多人在此分支上開發；

二、提測時，將 master 分支和須要提測的分支彙總到一個 release 分支，發佈測試環境；

三、發現bug時，在feature分支上debug後，再次回到2；

四、發佈生產環境後，將 release 分支合併到 master 分支，刪除release分支；

 

3、建立新項目（master分支）

開發主管提交代碼初始版本到master 分支，並推送至Gitlab系統；

開發主管在Gitlab 系統中設置master 分支爲Protectd 分支（保護分支）；

Protected 分支不容許Developer 角色推送代碼，但Master 角色能夠推送代碼；

 

4、進行項目開發（develop分支）

開發主管在master 分支上建立develop 分支（開發分支），並推送至Gitlab系統；

master 分支與develop 分支同樣，有且僅有一個；

對於非並行項目可使用develop分支開發方式，對於多人並行開發項目，使用feature分支開發方式，但develop和feature開發方式不該同時使用；

 

5、開發新特性（feature分支）

每一個新需求或新的研究建立一個feature 分支；

命名規範：

f-分支建立日期-新特性關鍵字，例如：f-20150508-滿立減；

推薦使用feature 分支，但feature 分支的生命週期不能跨一次迭代；

 

6、發佈測試環境（release分支）

開發負責人需完成如下任務：

1. 確認要發佈的feature 分支上的功能是否開發完畢並提交；

2. 建立release 分支（發佈分支），將全部要發佈的分支逐個合併到release分支，有以下狀況：

①.feature分支（可能有多個）

②.master分支（期間可能有其餘release版本更新到了master）

3. 命名規則：r-分支建立日期-新特性和待發布版本號，例如：r-201505081712-買立減v1.0.0，版本可根據須要添加;

4. 刪除本次發佈的全部feature分支;

5. 發佈到測試環境，通知測試;

 

7、修復待發布版本中的Bug（feature分支）

若是發現bug，開發人員在feature 分支上修復測試人員提交給本身的bug，修復完成後，由負責人再次建立 release 分支，發佈測試環境。

 

8、發佈正式環境

開發負責人需完成如下任務：

1. 根據修復後的release分支再次將master合併，打包發佈生產環境;

2. 確認發佈成功，併線上驗收經過後，將release分支合併到master分支;

3. 在master分支上建立標籤，命名規則：tag-日期-新特性和版本號，例如：tag-201505081712-買立減v1.0.0，版本可根據須要添加，做爲發版里程碑標記;

4. 刪除對應release 分支;

 

9、修復線上Bug（hotfix分支）

線上的不一樣版本出現了bug怎麼辦？開發負責人需完成如下任務：

1. 從master 分支某個tag 上建立一個hotfix 分支（熱修復分支），通常是最新的tag應該和當前生產環境對應；

命名規則：h-分支建立日期-bug名稱和待發布版本號，例如：h-201705081614-購物車點擊沒反應v1.0.1;

2. 開發人員完成Bug 修復，提交hotfix分支到測試環境驗收經過;

3. 再次發佈正式環境流程;

4. 將hotfix 分支合併到master分支;

5. 在master分支上建立標籤，命名規則：tag-日期-新特性和版本號，例如：tag-201505081712-買立減v1.0.0，版本可根據須要添加，做爲發版里程碑標記;

6. 刪除hotfix 分支;

 

10、Git 的特別注意事項

因爲 git 分支是基於指針的概念，因此分支速度很是快，當多個分支時，實際指針指向的是同一個文件，當文件被修改時，使用的是暫存區保存修改，此時並未提交到相應分支。

因此切換分支的時候，暫存區只有一個，因此切換分支以前，必定要將全部修改commit到當前分支，不然會在其餘分支看到修改的內容，引發誤解。

 

以上規範僅供參考，具體實踐請依據團隊具體狀況自行調整。。。