本文參考a-successful-git-branching-model
Git flow是基於git之上的一種軟件開發迭代模型。Git flow是使用git進行源代碼管理的一套行爲規範。
Git Flow重點解決的是由於源代碼在開發過程中的各種衝突導致開發活動混亂的問題，提高開發效率。
Git Flow中的分支
Git Flow模型中定義了主分支和輔助分支兩類分支。其中主分支用於組織與軟件開發、部署相關的活動；輔助分支組織爲了解決特定的問題而進行的各種開發活動。
主分支
- master分支
- develop 分支
輔助分支
我們的開發模式旁邊的主要分支機構掌握和發展，使用各種支持分支機構，以幫助團隊成員之間的平行發展，便於跟蹤的功能，準備生產版本，並協助快速修復現場生產問題。 與主分支不同，這些分支總是有有限的生命時間，因爲它們最終將被移除。
- feature分支
- release分支
- hotfix分支
feature 分支
- 從develop分支檢出
- 必須合併回develop分支
- 命名規範：除了
master, develop, release-*, or hotfix-*
當開始一個新特徵的開發時，從develop檢出feature分支。Feature分支的本質是，只要特性處於開發階段，它就會存在，將來會被合併會develop分支（爲了即將發佈的版本而明確地添加新特性），或者丟棄掉（如果是令人失望的實驗）。
Feature分支只存在於開發者本地，不能被提交到遠程庫
創建feature
Switched to a new branch “myfeature”
$ git checkout -b myfeature develop開發。。。
完成feature
完成的功能可以合併到develop分支，以明確將它們添加到即將發佈的版本中：
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin developrelease分支
- 從develop分支檢出
- 必須合併回develop分支和master分支
- 命名規範:
release-*
release分支是爲發佈新的產品版本而設計的。在這個分支上的代碼允許做小的缺陷修正、準備發佈版本所需的各項說明信息（版本號、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閒出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代週期。
當develop分支上的代碼已經包含了所有即將發佈的版本中所計劃包含的軟件功能，並且已通過所有測試時，我們就可以考慮準備創建release分支了。而所有在當前即將發佈的版本之外的業務需求一定要確保不能混到release分支之內（避免由此引入一些不可控的系統缺陷）。
創建一個release分支
Release分支從develop分支檢出。例如, 當前產品版本是1.1.5，我們有一個比較大的更新，develop分支已經做好發佈準備了，我們新的版本號定位1.2 (而不是1.1.6 或 2.0)。所以，我們從develop分支檢出release分支，命名爲release-1.2：
$ git checkout -b release-1.2 develop
$ ./bump-version.sh 1.2
$ git commit -a -m "Bumped version number to 1.2"
這個新的分支可能會存在一段時間，直到發佈可能被推出。 在此期間，可以在此分支做一些小的錯誤修復（而不是開發分支）。而不能添加大的新功能。
完成release分支
當release分支準備發佈時，需要執行一些操作。 首先，release分支被合併master分支（每往master提交一次，就是一個新的版本）。 接下來，對master的提交必須打tag，以便將來找到這個歷史版本。 最後，release分支所做的更改需要重新合併到develop分支，以便將來的版本也包含這些錯誤修復。
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2此時，已經發布完成，並打過了tag。
爲了保存release分支所做的更改，需要把release分支合併回develop分支
$ git checkout develop
$ git merge --no-ff release-1.2
這個操作可能會有衝突，合併衝突，提交就行了。
現在我們已經完成了，可以刪除release分支了，因爲我們不再需要它了：
$ git branch -d release-1.2hotfix分支：
- 從master檢出
- 合併會develop和master分支
- 命名：
hotfix-*
hotfix分支非常像release分支，因爲它們都意味着即將發佈一個新的版本，儘管是未計劃的。
當線上出現一個嚴重的bug，需要立即修復的時候，就需要從master分支上指定的tag版本派生hotfix分支來進行緊急修復工作。
這樣做的顯而易見的好處是不會打斷正在進行的develop分支的開發工作，能夠讓團隊中負責新功能開發的人與負責代碼緊急修復的人並行的開展工作。
創建hotfix
hotfix分支從master檢出。例如,當前線上運行的是1.2版本，出現了嚴重bug。而且develop分支還不夠穩定。可以從master檢出hotfix分支來修復bug：
$ git checkout -b hotfix-1.2.1 master
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"修復bug。。。
$ git commit -m "Fixed severe production problem"完成hotfix
當完成修復，hotfix分支需要合併到master，也要合併到develop分支，以便下個版本也包含這次修復。這個和完成release分支完全相似。
- 合併到master並打tag
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1- 合併到develop分支
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1注意：有一個例外，如果此時存在release分支時，就需要將hotfix分支合併到release分支，而不是develop分支。其實當release分支完成的時候，這次修復也就被合併到develop分支了。（如果在develop分支的工作立即需要修正這個錯誤，而不能等到release分支完成，也可以將後hotfix分支合併到develop分支。）
最後，刪除這個hotfix分支：
$ git branch -d hotfix-1.2.1summary
Git Flow開發模型從源代碼管理角度對通常意義上的軟件開發活動進行了約束。應該說，爲我們的軟件開發提供了一個可供參考的管理模型。Git Flow開發模型讓nvie的開發代碼倉庫保持整潔，讓小組各個成員之間的開發相互隔離，能夠有效避免處於開發狀態中的代碼相互影響而導致的效率低下和混亂。
所謂模型，在不同的開發團隊，不同的文化，不同的項目背景情況下都有可能需要進行適當的裁剪或擴充。