[轉載]理解 Git 分支管理最佳實踐

原文

理解 Git 分支管理最佳實踐

Git 分支有哪些

在進行分支管理講解以前，咱們先來對分支進行一個簡單的分類，並明確每一類分支的用途。

分支分類

根據生命週期區分

• 主分支：master，develop；
• 臨時分支：feature/*，release/*，hotfix/*；

根據用途區分

• 發佈/預發佈分支：master，release/*；
• 開發分支：develop；
• 功能分支：feature/*；
• 熱修復分支：hotfix/*；

分支的用途

• master：做爲發佈分支，隨時能夠將分支上的代碼部署到生產環境上。若是在生產環境上發現問題，則以 master 爲基準建立 hotfix/* 分支來修復問題；
• develop：做爲開發分支，全部最新的功能都將在該分支下進行開發，develop 也將是全部分支中功能最全，代碼最新的一個分支；
• feature/*：命名規則feature/功能名稱，做爲新功能的開發分支，該分支從 develop 建立，開發完畢以後須要從新合併到 develop；
• release/*：命名規則release/v+發佈的版本號，做爲預發佈分支，release/* 只能從 develop 建立，且在 git flow 中同一個時間點，只能存在一個預發佈分支。只有當上一個版本發佈成功以後刪除該分支，以後才能進行下一個版本的發佈。若是在預發佈過程當中發現了問題，只能在 release/* 分支上進行修改；
• hotfix/*：命名規則hotfix/v+bug修復的版本號，做爲熱修復分支，只能從 master 分支分離出來。主要是用來修復在生產環境上發現的 bug，修復完成並測試經過後須要將該分支合併回 develop 及 master 上，並刪除該分支；

Git 分支管理流程

在上一部分，咱們已經明確了每一個主分支及輔助分支的用途與來源了，下面咱們就來詳細瞭解一下 Git 分支管理的整個流程。
先來看一下分支在完整的功能開發中是如何演變的：

從上圖咱們能夠看出，咱們同時開始了兩個功能的開發/研究任務，下面我將以此爲基礎來說解分支管理的流程。

1. 先拉取最新的 develop 分支，而後以最新的 develop 爲基準建立兩個新的功能分支 feature/f1 和 feature/f2；

   git pull origin develop
   git checkout -b feature/f1 develop

2. 開發人員在各自的功能分支上進行開發工做，等當前功能分支開發完以後，將當前分支交由測試人員進行測試，測試過程當中的問題修復及功能修改均在當前功能分支上進行；

3. 當 feature/f1 上的開發及測試任務均完成以後，將 feature/f1 合併回 develop ，並刪除 feature/f1 ；

   git checkout develop
   git merge --no-ff feature/f1
   git branch -d feature/f1

4. 從 develop 分支建立新的預發佈分支 release/0.2，並部署到預發佈環境上測試。在預發佈過程當中發現問題則直接在 release/0.2 上進行修復；

   git checkout -b release/0.2 develop

5. 在生產環境中發現一個 bug，從 master 上分離出一個熱修復分支 hotfix/bug1，並在上面進行修復、測試並在預發佈環境中驗證，當都驗證經過以後將分支從新合併回 develop 及 master，並在 master 上打一個熱修復 tag v0.1.1，最後刪除 hotfix/bug1；

   git checkout -b hotfix/bug1 master
   ....................
   ....修復bug..ing....
   ....................
   git checkout develop
   git merge --no-ff hotfix/bug1
   git checkout master
   git merge --no-ff hotfix/bug1
   git tag v0.1.1
   git branch -d hotfix/bug1

6. 在 feature/f2 分支上的功能 f2 已經開發並測試完成，而後將 feature/f2 合併回 develop，並刪除 feature/f2，此時已經存在新功能 f1 的預發佈分支 release/0.2，因此須要等待其發佈完成以後才能建立預發佈分支 release/0.3；

   git checkout develop
   git merge --no-ff feature/f2
   git branch -d feature/f2

7. 預發佈分支 release/0.2 在預發佈環境中徹底測試經過，隨時能夠部署到生產環境。但在部署到生產環境以前，須要將分支合併回 develop 及 master，並在 release/0.2 上打一個正式發佈版本的 tag v0.2，最後刪除 release/0.2；

   git checkout develop
   git merge --no-ff release/0.2
   git checkout master
   git merge --no-ff release/0.2
   git tag v0.2
   git branch -d release/0.2

8. 當前已經不存在 release/* 預發佈分支，因此能夠開始功能 f2 的預發佈上線。建立預發佈分支 release/0.3，並部署預發佈環境測試；

   git checkout -b release/0.3 develop

9. 分支 release/0.3 測試經過，將 release/0.3 合併回 develop 及 master，而後在 master 上打一個正式發佈版本的 tag v0.3，最後刪除 release/0.3；

Git Flow

上述過程當中未使用到 git flow，均是以約定的規範流程進行，你們能夠嘗試使用 git flow 來管理分支。

 

#初始化 git flow
# 設置 feature、release、hotfix、tag 的前綴名
git flow init
 
#開始一個新功能 f1 的開發，以 develop 爲基準建立 feature/f1
git flow feature start f1
 
#....................
#....f1 功能開發中....
#....................
 
#新功能 f1 開發完成
# 合併回 develop
# 刪除 feature/f1 分支
git flow feature finish f1
 
#開始新功能 f1 的預發佈驗證，版本定爲 0.2
git flow release start 0.2
 
#新功能 f1 預發佈驗證經過
# 合併到 master 分支
# 在 release 上打 tag v0.2
# 將 tag v0.2 合併到 develop 分支
# 刪除 release/0.2 分支
git flow release finish 0.2
 
#開始 bug1 的修復，以 master 爲基準建立 hotfix/bug1
git flow hotfix start 0.2.1
 
# bug1 修復完成
# 合併到 master 分支
# 在 hotfix 上打 tag v0.2.1
# 將 tag v0.2.1 合併到 develop 分支
# 刪除 hotfix/0.2.1 分支
git flow hotfix finish 0.2.1

至此，Git 分支管理的整個流程已經講解完，有興趣的能夠看一下具體的分支管理演示 https://github.com/alienwow/gitbranchmanage。 

若是有上述講解中任何不正確的地方，歡迎你們批評指正，若有疑問歡迎一塊兒討論。

參考文章

Vincent Driessen A successful Git branching model
Joe Guo 介紹一個成功的 Git 分支模型