Git 分支管理規范

Git 倉庫申請流程

1. 開發主管向 Git 管理員提交 Git 倉庫申請【郵件:發送給 Git 管理員，抄送給項目經理，申請表可向 Git 管理員獲取】
2. Git 管理員審批開發主管的申請，審批以下具體信息:
   1. 審批郵件是否抄送給項目經理
   2. 申請的 Git 倉庫名稱是否符合命名規范
3. 若審批通過，則 Git 管理員完成以下任務:
   1. 創建 Git 倉庫
   2. 設置開發主管為 Git 倉庫的 Master 角色(管理員，具有該 Git 倉庫的管理權限)
   3. 將 Git 倉庫地址告知開發主管【郵件:發送給開發主管，抄送給項目經理】
4. 若審批不通過，則駁回申請【郵件:發送給開發主管，抄送給項目經理】

初始化 Git 倉庫

第一步:克隆遠程倉庫

開發主管從 Gitlab 中克隆遠程倉庫

命令示例:

git clone <倉庫地址> 

第二步:提交並推送初始版本

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

開發主管在 Gitlab 系統中設置 master 分支為 Protectd 分支(保護分支)Protected 分支不允許 Developer 推送代碼，但 Master 可以推送代碼

命令示例:

# 提交本地修改:
git add .
git commit –m “提交日志”
# 推送 master 分支:
git push origin master

第三步:創建開發分支

開發主管在 master 分支上創建 develop 分支(開發分支)，並推送至 Gitlab 系統 master

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

命令示例:

# 從 master 分支上創建 develop 分支: 
git checkout –b develop master
# 推送 develop 分支:
git push origin develop

開發新功能

開發人員在 develop 分支上實現新功能，包括:新特性與 Bug 修復

命令示例:

# 切換到 develop 分支: 
git checkout develop
# 提交本地修改:
git add .
git commit –m “提交日志”
# 推送 develop 分支:
git push origin develop

若存在多個新特性可以並行開發，則開發主管可創建一個或多個 feature 分支(特性分支)，命名規范:feature-分支創建日期-新特性關鍵字，例如:feature-20190919-i18n

當新特性開發完畢后，開發主管需將 feature 分支合並到 develop 分支，最后需刪除 feature 分支

命令示例:

# 從 develop 分支上創建 feature 分支:
git checkout –b feature-20190919-i18n develop
# 合並 feature 分支到 develop 分支: git checkout develop
git merge --no-ff feature
# 刪除本地 feature 分支:
git branch –d feature-20190919-i18n
# 刪除遠程 feature 分支:
git push origin :feature-20190919-i18n

什么時候需考慮使用 feature 分支?

1. 開發一個獨立的新特性(完成時，需合並到 develop 分支)
2. 技術研究與嘗試(若失敗，可隨時刪除 feature 分支)
3. 提前實現下一個版本需要開發的特性(可不在本次迭代中發布)

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

准備發布新版本

開發主管需完成以下任務:

1. 確認 develop 分支上的功能是否開發完畢

2. 若開發完畢，則創建 release 分支(發布分支)，命名規則:release-分支創建日期-待發布版本號，例

   如:release-20190919-v1.0.0

3. 首先在 release 分支中升級 Maven 版本號，例如:1.0.0-SNAPSHOT，然后修改 version.ini 文件(便於在

   部署時查看當前版本號)，最后在 release 分支上做一次提交

4. 通知測試主管可對 release 分支進行測試【郵件:發送給測試經理，抄送給項目經理與團隊成員】

命令示例:

# 從 develop 分支上創建 release 分支:
git checkout –b release-20190919-v1.0.0 develop

修復待發布版本中的 Bug

開發人員在 release 分支上修復測試人員提交給自己的 Bug

只允許在 release 分支上修復 Bug，不允許提交任何新特性，開發主管需全程監管

命令示例:

# 切換到 release 分支:
git checkout release-20190919-v1.0.0
# 提交本地修改:
git add .
git commit –m “提交日志”
# 推送 release 分支:
git push origin release-20190919-v1.0.0

發布新版本

第一步:集成測試

測試主管需完成以下任務:

1. 從 release 分支上檢出所有代碼並搭建集成測試環境
2. 安排測試人員，對 release 分支進行集成測試
3. 通知開發主管當前版本已集成測試完畢【郵件:發送給開發主管，抄送給項目經理】

第二步:冒煙測試

開發主管需完成以下任務:

1. 將 release 分支同時合並到 master 分支與 develop 分支
2. 郵件通知測試主管，對 master 分支進行冒煙測試

第三步:發布新版本

開發主管需完成以下任務:

1. 修改 master 分支上的 Maven 快照版為發布版(去掉 SNAPSHOT 后綴)
2. 添加發布日志(RELEASE.md)
3. 在 master 分支上創建標簽，命名規則:tag-日期-版本，例如:tag-20190919-v1.0.0
4. 刪除 release 分支
5. 打包並上傳 Maven 私服
6. 通知測試主管新版本已發布完畢【郵件:發送給測試主管，抄送給項目經理與 Git 管理員，郵件格式
   請找 Git 管理員獲取】

命令示例:

# 合並 release 分支到 master 分支:
git checkout master
git merge --no-ff release-20190919-v1.0.0
# 合並 release 分支到 develop 分支:
git checkout develop
git merge --no-ff release-20190919-v1.0.0
# 在 master 分支上創建標簽:
git tag tag-20190919-v1.0.0
# 刪除本地 release 分支:
git branch –d release-20190919-v1.0.0
# 刪除遠程 release 分支:
git push origin :release-20190919-v1.0.0

修復線上 Bug

第一步:創建 hotfix 分支 開發主管需完成以下任務:

1. 從 master 分支某個 tag 上創建一個 hotfix 分支(熱修復分支)，命名規則:hotfix-分支創建日期-待
   發布版本號，例如:hotfix-20190919-v1.0.1
2. 首先在 hotfix 分支中升級 Maven 版本號(例如:1.0.1-SNAPSHOT)，然后修改 version.ini 文件，最后在
   hotfix 分支上做一次提交
3. 指導開發人員完成 Bug 修復
4. 通知測試主管對 hotfix 分支進行測試【郵件:發送給測試主管，抄送給項目經理】

命令示例:

# 從某個標簽上創建 hotfix 分支:
git branch hotfix-20190919-v1.0.1 tag-20190919-v1.0.0

第二步:驗證 Bug 是否已修復測試主管需完成以下任務:

1. 驗證 Bug 是否已修復
2. 通知開發主管 Bug 已修復【郵件:發送給開發主管，抄送給項目經理】

第三步:創建標簽並發布新版本

開發主管需完成以下任務:

1. 將 hotfix 分支同時合並到 master 與 develop 分支
2. 通過測試主管進行冒煙測試

第四步:發布新版本

開發主管需完成以下任務:

1. 修改 master 分支上的 Maven 快照版為發布版(去掉 SNAPSHOT 后綴)
2. 添加發布日志(RELEASE.md)
3. 在 master 分支上創建標簽
4. 刪除 hotfix 分支
5. 打包並上傳 Maven 私服
6. 通知測試主管新版本已發布完畢【郵件:發送給測試主管，抄送給項目經理與 Git 管理員，郵件格式

請找 Git 管理員獲取】

命令示例:

# 合並 hotfix 分支到 master 分支:
git checkout master
git merge --no-ff hotfix-20190919-v1.0.1
# 合並 hotfix 分支到 develop 分支:
git checkout develop
git merge --no-ff hotfix-20190919-v1.0.1
# 在 master 分支上創建標簽:
git checkout master
git tag tag-20190919-v1.0.1
# 刪除本地 hotfix 分支:
git branch –d hotfix-20190919-v1.0.1
# 刪除遠程 hotfix 分支:
git push origin :hotfix-20190919-v1.0.1

若無法將 hotfix 分支合並到 master 與 develop 分支時，應該如何發布?

比如:現在 master 分支已經發布了 2.0.0 版本(代碼結構發生了很大的變化)，但線上發現了一個 1.0.0 版 本的 Bug，當修改了 Bug后，是無法再合並到 master 與 develop 分支的，開發主管需完成以下任務:

1. 直接在 hotfix 分支上創建標簽
2. 刪除 hotfix 分支(分支刪除了，只要標簽還在，版本就可以找得回來)
3. 手工修改 develop 分支中的代碼(在后續發布時再合並到 master 分支中)

定制化項目

當需要對某項目進行定制化時，可從源項目的 Git 倉庫 fork 出一個新的 Git 倉庫:

當 fork 后，對 repo1 做出的任何修改，都不會影響到 repo2
在 repo2 中修復了 Bug，可通過 Merge Request 的方式提交給 repo1
在 repo2 中可隨時拉取 repo1 中的提交，但 repo1 不能拉取 repo2 中的提交

附錄

Maven 版本號命名規范

格式:Major.Minor.Micro

版本	說明
Major 版本	架構調整
Minor 版本	新特性
Micro 版本	Bug 修復、優化

Git 分支類型

分支	用途
master 分支(主分支)	穩定版本
develop 分支(開發分支)	最新版本
release 分支(發布分支)	發布新版本
hotfix 分支(熱修復分支)	修復線上 Bug
feature 分支(特性分支)	實現新特性

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

Gitlab 角色	項目角色
Owner(擁有者)	Git 管理員
Master(管理員)	開發主管
Developer(開發者)	開發人員
Reporter(報告者)	測試人員
Guest(觀察者)	其他人員

Git 管理員與開發主管的職責

Git 管理員	開發主管
創建 Git 倉庫	管理項目分支
檢查 Git 分支規范	成員管理
維護 Gitlab 系統	管理標簽

來源：Git分支管理規范