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 f1git-flow 從 develop 分支創建了一個新的分支 feature/f1，并自動切換到這個分支下面。然后就可以進行 f1 功能開發，中間可以多次的 commit 操作。將一個 f1 分支推到遠程服務器，與其他開發人員協同開發：
? git flow feature publish f1 或者 ? git push origin feature/f1 -
完成功能開發，結束新功能分支并刪除：
? git flow feature finish f1feature/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 deletedgit-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；
