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個臨時的輔助分支:
主要分支
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
-
基於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
;