GIT版本管理：Git Flow模型

時間 2019-11-21

標籤 git 版本管理 flow 模型欄目 Git 简体版

原文原文鏈接

1 Git Flow介紹

咱們都知道, 在 git 的分支功能相對 svn 確實方便許多，並且也很是推薦使用分支來作開發. 個人作法是每一個項目都有2個分支, master 和 develop. master 分支是主分支, 保證程序有一個穩定版本, develop 則是開發用的分支, 幾乎全部的功能開發, bug 修復都在這個分支上, 完成後再合併回 master.git

可是狀況並非這麼簡單. 有時當咱們正在開發一個功能, 但程序忽然出現 bug 須要及時去修復的時候, 這時要切回 master 分支, 並基於它建立一個 hotfix 分支. 有時咱們在開發一個功能時, 須要停下來去開發另外一個功能. 並且全部這些問題都出現的時候, 發佈也會成爲比較棘手問題.bash

也就是說, 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 仍是比較複雜的，尤爲是在多分支狀況下)，簡單並且規範的解決了代碼分支管理問題。svn

簡單來講, Git Flow將 branch 分紅2個主要分支和3個臨時的輔助分支：微服務

主要分支工具

master: 永遠處在**即將發佈(production-ready)狀態**；測試

develop: 最新的開發狀態；fetch

輔助分支spa

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

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

基於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
複製代碼
```
完成功能開發，結束新功能分支並刪除：
```
➜ git flow feature finish f1
複製代碼
```
feature/f1 分支的代碼會被合併到 develop 裏面，而後刪除該分支，切換回 develop. 到此，新功能開發這個場景完畢。在 f1 功能開發中，若是 f1 未完成，同時功能 f2 要開始進行，也是能夠的。

2.3 場景2：發佈上線，代號 0.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'
複製代碼

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
複製代碼

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

基於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'
複製代碼

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 一種的經典分支管理規範

如上圖所示：

最穩定的代碼放在 master 分支上（至關於 SVN 的 trunk 分支），咱們不要直接在 master 分支上提交代碼，只能在該分支上進行代碼合併操做，例如將其它分支的代碼合併到 master 分支上。
咱們 平常開發中的代碼須要從 master 分支拉一條 develop 分支出來，該分支全部人都能訪問，但通常狀況下，咱們也不會直接在該分支上提交代碼，代碼一樣是從其它分支合併到 develop 分支上去。
當咱們須要開發某個特性時，須要從 develop 分支拉出一條 feature 分支，例如 feature-1 與 feature-2，在這些分支上並行地開發具體特性。
當特性開發完畢後，咱們決定須要發佈某個版本了，此時須要從 develop 分支上拉出一條 release 分支，例如 release-1.0.0，並將須要發佈的特性從相關 feature 分支一同合併到 release 分支上，隨後將針對 release 分支部署測試環境，測試工程師在該分支上作功能測試，開發工程師在該分支上修改 bug。
待測試工程師沒法找到任何 bug 時，咱們可將該 release 分支部署到預發環境，再次驗證之後，均無任何 bug，此時可將 release 分支部署到生產環境。
待上線完成後，將 release 分支上的代碼同時合併到 develop 分支與 master 分支，並在 master 分支上打一個 tag，例如 v1.0.0。
當生產環境發現 bug 時，咱們 須要從對應的 tag 上（例如 v1.0.0）拉出一條 hotfix 分支（例如 hotfix-1.0.1），並在該分支上作 bug 修復。待 bug 徹底修復後，需將 hotfix 分支上的代碼同時合併到 develop 分支與 master 分支。

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

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

feature分支開發完成後，暫時不合並至develop，而是基於develop開啓release分支，將feature分支合併到release分支，進行測試；

release分支測試經過後，部署到生產環境，將release分支代碼合併到develop分支與master分支，並在master分支打一個tag；