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

1. 首先在 hotfix 分支中升級 Maven 版本號(例如:1.0.1-SNAPSHOT)，而後修改 version.ini 文件，最後在

hotfix 分支上作一次提交

1. 指導開發人員完成 Bug 修復
2. 通知測試主管對 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分支管理規範