本文參考a-successful-git-branching-model
Git flow是基于git之上的一種軟件開發(fā)迭代模型。Git flow是使用git進行源代碼管理的一套行為規(guī)范沛婴。
Git Flow重點解決的是由于源代碼在開發(fā)過程中的各種沖突導致開發(fā)活動混亂的問題撞羽，提高開發(fā)效率喇完。
Git Flow中的分支
Git Flow模型中定義了主分支和輔助分支兩類分支肴沫。其中主分支用于組織與軟件開發(fā)歉井、部署相關的活動兄淫；輔助分支組織為了解決特定的問題而進行的各種開發(fā)活動。
主分支
- master分支
- develop 分支
輔助分支
我們的開發(fā)模式旁邊的主要分支機構掌握和發(fā)展沈条，使用各種支持分支機構需忿，以幫助團隊成員之間的平行發(fā)展，便于跟蹤的功能蜡歹，準備生產(chǎn)版本屋厘，并協(xié)助快速修復現(xiàn)場生產(chǎn)問題。 與主分支不同月而，這些分支總是有有限的生命時間汗洒，因為它們最終將被移除。
- feature分支
- release分支
- hotfix分支
feature 分支
- 從develop分支檢出
- 必須合并回develop分支
- 命名規(guī)范：除了
master, develop, release-*, or hotfix-*
當開始一個新特征的開發(fā)時父款，從develop檢出feature分支溢谤。Feature分支的本質是瞻凤，只要特性處于開發(fā)階段，它就會存在世杀，將來會被合并會develop分支（為了即將發(fā)布的版本而明確地添加新特性）阀参，或者丟棄掉（如果是令人失望的實驗）。
Feature分支只存在于開發(fā)者本地瞻坝，不能被提交到遠程庫
創(chuàng)建feature
Switched to a new branch "myfeature"
$ git checkout -b myfeature develop
開發(fā)蛛壳。。所刀。
完成feature
完成的功能可以合并到develop分支衙荐，以明確將它們添加到即將發(fā)布的版本中：
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
release分支
- 從develop分支檢出
- 必須合并回develop分支和master分支
- 命名規(guī)范:
release-*
release分支是為發(fā)布新的產(chǎn)品版本而設計的。在這個分支上的代碼允許做小的缺陷修正浮创、準備發(fā)布版本所需的各項說明信息（版本號忧吟、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交斩披，進入新的軟件開發(fā)迭代周期溜族。
當develop分支上的代碼已經(jīng)包含了所有即將發(fā)布的版本中所計劃包含的軟件功能，并且已通過所有測試時雏掠，我們就可以考慮準備創(chuàng)建release分支了斩祭。而所有在當前即將發(fā)布的版本之外的業(yè)務需求一定要確保不能混到release分支之內（避免由此引入一些不可控的系統(tǒng)缺陷）劣像。
創(chuàng)建一個release分支
Release分支從develop分支檢出乡话。例如, 當前產(chǎn)品版本是1.1.5，我們有一個比較大的更新耳奕，develop分支已經(jīng)做好發(fā)布準備了绑青，我們新的版本號定位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"
這個新的分支可能會存在一段時間，直到發(fā)布可能被推出芍躏。 在此期間邪乍，可以在此分支做一些小的錯誤修復（而不是開發(fā)分支）。而不能添加大的新功能对竣。
完成release分支
當release分支準備發(fā)布時庇楞，需要執(zhí)行一些操作。 首先否纬，release分支被合并master分支（每往master提交一次吕晌，就是一個新的版本）。 接下來临燃，對master的提交必須打tag睛驳，以便將來找到這個歷史版本烙心。 最后，release分支所做的更改需要重新合并到develop分支乏沸，以便將來的版本也包含這些錯誤修復淫茵。
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
此時，已經(jīng)發(fā)布完成蹬跃，并打過了tag痘昌。
為了保存release分支所做的更改，需要把release分支合并回develop分支
$ git checkout develop
$ git merge --no-ff release-1.2
這個操作可能會有沖突炬转，合并沖突辆苔，提交就行了。
現(xiàn)在我們已經(jīng)完成了扼劈，可以刪除release分支了驻啤，因為我們不再需要它了：
$ git branch -d release-1.2
hotfix分支：
- 從master檢出
- 合并會develop和master分支
- 命名：
hotfix-*
hotfix分支非常像release分支，因為它們都意味著即將發(fā)布一個新的版本荐吵，盡管是未計劃的骑冗。
當線上出現(xiàn)一個嚴重的bug，需要立即修復的時候先煎，就需要從master分支上指定的tag版本派生hotfix分支來進行緊急修復工作贼涩。
這樣做的顯而易見的好處是不會打斷正在進行的develop分支的開發(fā)工作，能夠讓團隊中負責新功能開發(fā)的人與負責代碼緊急修復的人并行的開展工作薯蝎。
創(chuàng)建hotfix
hotfix分支從master檢出遥倦。例如,當前線上運行的是1.2版本，出現(xiàn)了嚴重bug占锯。而且develop分支還不夠穩(wěn)定袒哥。可以從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.1
summary
Git Flow開發(fā)模型從源代碼管理角度對通常意義上的軟件開發(fā)活動進行了約束。應該說赶撰，為我們的軟件開發(fā)提供了一個可供參考的管理模型舌镶。Git Flow開發(fā)模型讓nvie的開發(fā)代碼倉庫保持整潔，讓小組各個成員之間的開發(fā)相互隔離豪娜，能夠有效避免處于開發(fā)狀態(tài)中的代碼相互影響而導致的效率低下和混亂餐胀。
所謂模型，在不同的開發(fā)團隊瘤载，不同的文化否灾，不同的項目背景情況下都有可能需要進行適當?shù)牟眉艋驍U充。
