git flow分支管理

閱讀目錄

• 兩種核心分支
• 三種臨時分支
• Git Flow流程示例代碼
• Git Flow工具
• 分支命名規范
• 總結

git flow是Vincent Driessen提出了一個分支管理的策略，非常值得借鑒。它可以使得版本庫的演進保持簡潔，主干清晰，各個分支各司其職、井井有條。

先看下Vincent Driessen提出的分支管理模型圖，以便對git flow有個大概的了解。

回到頂部

兩種核心分支

主分支(Master)：代碼庫應該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發布。這個分支只能從其它分支合並，不能在這個分支上直接修改。需要注意的是，所有在master上的提交應該標記tag。

開發主分支(Develop)：這個分支是我們是我們的主開發分支，包含所有要發布到下一個Release的代碼，這個主要合並與其他分支，比如Feature分支。該分支應該只是進行一些優化和升級開發，如果有新的需求應該拉出一個feature分支。

回到頂部

三種臨時分支

功能(feature)分支：這個分支主要是用來開發一個新的功能，一旦開發完成，我們合並回Develop分支進入下一個Release。

預發布(release)分支：當你需要一個發布一個新Release的時候，我們基於Develop分支創建一個Release分支，完成Release后，我們合並到Master和Develop分支。

修補bug(hotfix)分支：當我們在Production發現新的Bug時候，我們需要創建一個Hotfix, 完成Hotfix后，我們合並回Master和Develop分支，所以Hotfix的改動會進入下一個Release。

這三種分支都屬於臨時性需要，使用完以后，應該刪除，使得代碼庫的常設分支始終只有master和develop。

回到頂部

Git Flow流程示例代碼

1，創建develop分支

#從master拉出develop分支

#可選，獲取最新版本。git pull origin master

git checkout -b develop master

#發布develop分支

git push -u origin develop

2，創建feature分支

#從develop拉出feature_v1.0功能分支

#可選，獲取最新版本。git pull origin develop

git checkout -b feature_v1.0 develop

#發布feature_v1.0分支

git push -u origin feature_v1.0

#在feature_v1.0上開發一些功能

3，完成feature，合並到develop分支

#develop分支獲取最新

git pull origin develop

#切換到develop分支

git checkout develop

#從feature分支合並到develop分支

git merge --no-ff feature_v1.0

#刪除feature分支，也可以不刪除

git branch -d feature_v1.0

4，開始release

#從develop拉出一個release分支

#可選，獲取最新版本。git pull origin develop

git checkout -b release_v1.0 develop

#fix bugs

5，完成release，合並到master分支和develop分支，在master打上tag標記

#合並到master

git checkout master

git merge --no-ff release_v1.0

#在master打tag標記

git tag release1.0 master

git push --tags

#合並到develop

git checkout develop

git merge --no-ff release_v1.0

6，開始hotfix

#從主線master拉出一個hotfix分支

#可選，獲取最新版本。git pull origin master

git checkout -b hotfix_v1.0.1 master

7，完成hotfix，合並到master和develop，並在master上打tag。

#合並hotfix_v1.0.1到master

git checkout master

git merge --no-ff hotfix_v1.0.1

#在master打上tag

git tag hotfix1.0.1 master

git push --tags

#合並hotfix_v1.0.1到develop

git checkout develop

git merge --no-ff hotfix_v1.0.1

回到頂部

Git Flow工具

1，SourceTree

2，GitFlow for Visual Studio

回到頂部

分支命名規范

feature分支：以"feature_"開頭，如feature_v1.1

release分支：以"release_"開頭，如release_v1.1

hotfix分支：以"hotfix_"開頭，如hotfix_20160112

tag標記：如果是release分支合並，則以"release_"開頭。如果是hotfix分支合並，則以"hotfix_"開頭。

master分支每次提交都要打tag，release tag：如release_v1.1，hotfix tag：如hotfix_20160112

命名都統一采用小寫。

回到頂部

總結

1，一定要按git flow的流程去管理分支，如feature分支開發完要合並到develop，如果要發布版本到test環境，則從develop拉出一個release分支，release完成后要合並回master和develop分支，修復生產環境問題需要從master拉出一個hotfix分支，hotfix完成后要合並回master和develop分支，並且在master打上tag。

2，一定要按分支命名規范來命名，便於管理和維護。

3，了解了git flow工作流程后，可以不使用git flow GUI工具，手動操作即可，可以是原生git命令+vs配合操作，比如給master打tag就要用git命令，這在vs里操作不了的，比如合並分支，雖然也可以使用git命令實現，但在vs里操作更方便直觀。

4，一定要保持分支的純凈，不要隨便污染分支。比如，develop分支只包含要發布到下一個release的代碼，在沒有拉出release分支前不要合並新的feature分支進來。release分支基於develop分支創建，拉出release分支后，我們可以在這個release分支上測試和修復bug，但是，一旦打了release分支后不要從develop分支合並新的改動過來。develop拉出release分支的同時，也意味着develop分支可以開始下一個release的准備工作了。

5，如果多個版本並行到test環境，怎么解決這個問題？如下圖。