GIT版本管理:Git Flow模型

猿碼道發表於2017-12-27

1 Git Flow介紹

我們都知道, 在 git 的分支功能相對 svn 確實方便許多,而且也非常推薦使用分支來做開發. 我的做法是每個專案都有2個分支, master 和 develop. master 分支是主分支, 保證程式有一個 穩定版本, develop 則是開發用的分支, 幾乎所有的功能開發, bug 修復都在這個分支上, 完成後再合併回 master.

但是情況並不是這麼簡單. 有時當我們正在開發一個功能, 但程式突然出現 bug 需要及時去修復的時候, 這時要切回 master 分支, 並基於它建立一個 hotfix 分支. 有時我們在開發一個功能時, 需要停下來去開發另一個功能. 而且所有這些問題都出現 的時候, 釋出也會成為比較棘手問題.

也就是說, git branch 功能很強大,但是沒有一套模型告訴我們應該怎樣在開發的時候善用這些分支。而Git Flow模型就是要告訴我們怎麼更好地使用Git分支。

簡單來說,git-flow 就是在 git branch git tag基礎上封裝出來的程式碼分支管理模型,把實際開發模擬成 master develop feature release hotfix support 幾種場景,其中 master 對應釋出上線,develop 對應開發,其他幾個在不同的情況下出現。通過封裝,git-flow 遮蔽了 git branch 等相對來說比較複雜生硬的命令(git branch 還是比較複雜的,尤其是在多分支情況下),簡單而且規範的解決了程式碼分支管理問題

簡單來說, Git Flow將 branch 分成2個主要分支和3個臨時的輔助分支:

GIT版本管理:Git Flow模型

主要分支

master: 永遠處在**即將釋出(production-ready)狀態**;

develop: 最新的開發狀態

輔助分支

feature: 開發新功能的分支, 基於 develop, 完成後 merge 回 develop

release: 準備要釋出版本的分支, 用來修復 bug. 基於 develop, 完成後 merge 回 develop 和 master

hotfix: 修復 master 上的問題, 等不及 release 版本就必須馬上上線. 基於 master, 完成後 merge 回 master 和 develop

2 Git Flow使用

2.1 Git Flow安裝構建

安裝 git-flow:

➜ brew install git-flow
複製程式碼

作者還提供了 git-flow 命令工具,在一個全新目錄下構建 git-flow 模型:

➜ git flow init
複製程式碼

接著它會問你一系列的問題,蛋定!儘量使用它的預設值就好了:

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
複製程式碼

或者在現有的版本庫構建:

➜ git flow init
Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
複製程式碼

這樣一個 git-flow 分支模型就初始化完成。

2.2 場景1:新功能開發,代號 f1

  1. 基於develop,開啟新功能分支開發

    完成前面構建操作,當前所在分支就變成 develop. 任何開發都必須從 develop 開始:

    ➜ git flow feature start f1
    複製程式碼

    git-flow 從 develop 分支建立了一個新的分支 feature/f1,並自動切換到這個分支下面。然後就可以進行 f1 功能開發,中間可以多次的 commit 操作。

    將一個 f1 分支推到遠端伺服器,與其他開發人員協同開發:

    ➜ git flow feature publish f1
    
    或者
    
    ➜ git push origin feature/f1
    複製程式碼
  2. 完成功能開發,結束新功能分支並刪除:

    ➜ git flow feature finish f1
    複製程式碼

    feature/f1 分支的程式碼會被合併到 develop 裡面,然後刪除該分支,切換回 develop. 到此,新功能開發這個場景完畢。在 f1 功能開發中,如果 f1 未完成,同時功能 f2 要開始進行,也是可以的。

2.3 場景2:釋出上線,代號 0.1

  1. 基於develop,開發釋出分支

    ➜ git flow release start 0.1
    Switched to a new branch 'release/0.1'
    
    Summary of actions:
    - A new branch 'release/0.1' was created, based on 'develop'
    - You are now on branch 'release/0.1'
    
    Follow-up actions:
    - Bump the version number now!
    - Start committing last-minute fixes in preparing your release
    - When done, run:
    
    git flow release finish '0.1'
    複製程式碼
  2. git-flow 從 develop 分支建立一個新的分支 release/0.1,並切換到該分支下,接下來要做的就是修改版本號等釋出操作。完成後:

    ➜ git flow release finish 0.1
    Switched to branch 'master'
    Merge made by the 'recursive' strategy.
     f1      |    1 +
     version |    1 +
     2 files changed, 2 insertions(+)
     create mode 100644 f1
     create mode 100644 version
    Switched to branch 'develop'
    Merge made by the 'recursive' strategy.
     version |    1 +
     1 file changed, 1 insertion(+)
     create mode 100644 version
    Deleted branch release/0.1 (was d77df80).
    
    Summary of actions:
    - Latest objects have been fetched from 'origin'
    - Release branch has been merged into 'master'
    - The release was tagged '0.1'
    - Release branch has been back-merged into 'develop'
    - Release branch 'release/0.1' has been deleted
    複製程式碼
  3. git-flow 會依次切換到 master develop 下合併 release/0.1 裡的修改,然後用 git tag 的給當次釋出打上 tag 0.1,可以通過 git tag 檢視所有 tag:

    ➜ git:(master) git tag
    0.1
    0.2
    複製程式碼

2.3 場景3:緊急 bug 修正,代號 bug1

  1. 基於master,開啟熱修復分支

    ➜ git flow hotfix start bug1
    Switched to a new branch 'hotfix/bug1'
    
    Summary of actions:
    - A new branch 'hotfix/bug1' was created, based on 'master'
    - You are now on branch 'hotfix/bug1'
    
    Follow-up actions:
    - Bump the version number now!
    - Start committing your hot fixes
    - When done, run:
    
    git flow hotfix finish 'bug1'
    複製程式碼
  2. git-flow 從 master 分支建立一個新的分支 hotfix/bug1,並切換到該分支下。接下來要做的就是修復 bug,完成後:

    ➜ git flow hotfix finish bug1
    Switched to branch 'master'
    Merge made by the 'recursive' strategy.
     f1 |    2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    Switched to branch 'develop'
    Merge made by the 'recursive' strategy.
     f1 |    2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    Deleted branch hotfix/bug1 (was aa3ca2e).
    
    Summary of actions:
    - Latest objects have been fetched from 'origin'
    - Hotfix branch has been merged into 'master'
    - The hotfix was tagged 'bug1'
    - Hotfix branch has been back-merged into 'develop'
    - Hotfix branch 'hotfix/bug1' has been deleted
    複製程式碼

    git-flow 會依次切換到 master develop 分支下合併 hotfix/bug1,然後刪掉 hotfix/bug1。到此,hotfix 完成。

    git-flow 的 feature release 都是從 develop 分支建立,hotfix support 都是從 master 分支建立。

3 一種的經典分支管理規範

GIT版本管理:Git Flow模型

如上圖所示:

  1. 最穩定的程式碼放在 master 分支上(相當於 SVN 的 trunk 分支),我們不要直接在 master 分支上提交程式碼,只能在該分支上進行程式碼合併操作,例如將其它分支的程式碼合併到 master 分支上。

  2. 我們 日常開發中的程式碼需要從 master 分支拉一條 develop 分支出來,該分支所有人都能訪問,但一般情況下,我們也不會直接在該分支上提交程式碼,程式碼同樣是從其它分支合併到 develop 分支上去

  3. 當我們需要開發某個特性時,需要從 develop 分支拉出一條 feature 分支,例如 feature-1 與 feature-2,在這些分支上並行地開發具體特性。

  4. 當特性開發完畢後,我們決定需要釋出某個版本了,此時需要從 develop 分支上拉出一條 release 分支,例如 release-1.0.0,並將需要釋出的特性從相關 feature 分支一同合併到 release 分支上,隨後將針對 release 分支部署測試環境,測試工程師在該分支上做功能測試,開發工程師在該分支上修改 bug。

  5. 待測試工程師無法找到任何 bug 時,我們可將該 release 分支部署到預發環境,再次驗證以後,均無任何 bug,此時可將 release 分支部署到生產環境

  6. 待上線完成後,將 release 分支上的程式碼同時合併到 develop 分支與 master 分支,並在 master 分支上打一個 tag,例如 v1.0.0。

  7. 當生產環境發現 bug 時,我們 需要從對應的 tag 上(例如 v1.0.0)拉出一條 hotfix 分支(例如 hotfix-1.0.1),並在該分支上做 bug 修復。待 bug 完全修復後,需將 hotfix 分支上的程式碼同時合併到 develop 分支與 master 分支

對於版本號我們也有要求,格式為:x.y.z,其中,x 用於有重大重構時才會升級,y 用於有新的特性發布時才會升級,z 用於修改了某個 bug 後才會升級。針對每個微服務,我們都需要嚴格按照以上開發模式來執行。

與Git Flow模型分支管理的區別點:

  1. feature分支開發完成後,暫時不合並至develop,而是基於develop開啟release分支,將feature分支合併到release分支,進行測試;

  2. release分支測試通過後,部署到生產環境,將release分支程式碼合併到develop分支與master分支,並在master分支打一個tag

相關文章