轉載：http://blog.csdn.net/victor_barnett/article/details/51211282
這幾天看詳細了一下Git Flow的模型介紹，感覺“很好很強大”，這個開發模型利用Git的易於分支和合並的特點，能夠比較容易地將開發、發布、部署、bug修復分隔開來。
正准備在自己的團隊內部推廣使用，比較擔心的是管理工作稍微繁瑣一點。操作倒不復雜，只是需要頭腦清醒，熟悉不同分支間的派生、合並關系和時機。沒想到“正在瞌睡的時候送來了一個枕頭”，正在使用的SourceTree工具天然支持Git Flow，而且把這個模型的各種操作通過菜單命令的形式提供了出來，大大減輕了使用人員的學習使用成本。
為了能讓大家少走彎路，也便於我盡快熟練使用，我進行了摸索和實踐，下面把具體的使用方式記錄下來供參考。
入口
SourceTree界面頂部的工具欄按鈕，從右至左第二個“GIT工作流”圖標就是。
初始化
為了便於展示，我在自己的一個Github項目上進行相關的操作。進入這個項目，然后點擊剛剛的“GIT工作流”工具欄按鈕。
建議不用做任何改動，直接“確定”即可。SourceTree會自動化進行一些操作，最明顯的變化是項目代碼庫里自動增加了一個develop的分支。
將新創建的develop分支推送到遠端倉庫。
我們到Github里看這個項目的分支關系圖如下：
從此，代碼庫里就存在了兩個永久性的分支：master和develop，未來所有的開發工作都圍繞這兩個分支進行派生跟合並。派生和合並的時機、源分支、目標分支跟具體的開發類型有關，Gitflow里有明確的規則，如果純粹使用命令行工具的話，需要牢記這些規則並正確執行。而SourceTree則把這些規則用具體功能自動化實現了，這樣就能減少人為的失誤，至少在我剛開始手動完成這些操作的時候，失誤的幾率還是挺高的。
從初始化的第一個界面中，還有三類分支的命名規則：feature、release、hotfix，這就是未來承接具體開發工作的分支類型，從名稱中就能准確把握他們的用途。
創建分支
上面提到，項目里有兩個永久的分支：master和develop。這兩個分支也被稱為“歷史性”分支，在其后的開發工作中，Gitflow模型支持在feature、release、hotfix分支上折騰，這樣也有效避免了不同類型的開發工作在代碼層級的耦合和干擾。
這三個分支的用途、派生來源分支和合並目標分支如下：
feature，功能開發分支，用於承接具體功能需求的開發
- 派生於develop
- 合並於develop
hotfix，bug修復分支，用於解決線上運行環境發現的bug
- 派生於master
- 合並於master、develop
release，版本發布分支，用於完成發布准備的
- 派生於develop
- 合並於master、develop
跟“歷史性”分支相反，這三類分支都是短期分支，針對他們的工作內容完成后，一般都要進行刪除。工作內容完成的標識有兩個：開發完成、合並完成，缺一不可。
hotfix
正式環境正在運行的項目發現了一個bug，需要創建hotfix分支進行bug修復，在已經做過Gitflow初始化的項目上點擊工具欄上的“Gitflow”按鈕，出現如下窗口：
但有時候我們已經在庫里創建了一個還未完成的分支，就會看到這個窗口：
點擊“建立新的修復補丁”：
輸入自己想要的分支名稱，“確定”即可創建，從預覽圖中可以看到分支派生來源以及派生出來的分支信息。這里有一點要注意，hotfix分支的名稱在最終合並到master時會自動變成標簽，而一般來說，master的標簽往往標識版本號，比如1.0.0，所以這個分值名稱最好能夠按照版本規則來命名，比如1.0.1。
hotfix分支創建完成后，在分支目錄結構里能夠看到它：
經過一系列艱苦卓越的工作，這個bug修復完成了，就要合並到master和develop，在SourceTree里，只要通過點擊“Gitflow”工具欄即可指導你完成：
點擊第一個“完成修復補丁”：
這個操作默認“刪除分支”，將把本地的修復分支刪除掉，因為它的使命已經完成。合並時如果出現沖突，還是需要開發人員自行解決的。這時能夠在“預覽”位置看到這個hotfix分支的合並關系示意圖。
合並后將代碼庫推送到遠端，這時在Github上可以看到這些分支的關聯關系：
中間的藍色分支既是這個hotfix分支，從圖中可以看到這個分支先后被合並到了master和develop上。因為我沒有把這個分支提交到Github，所以只有圖形示意，沒有類似master和develop的名稱指示。
feature
當接到具體的功能需求時，開發人員需要派生feature分支，在SourceTree上，派生的工作相當簡單，只要在已經做過Gitflow初始化的項目上點擊工具欄上的“Gitflow”按鈕，出現如下窗口：
點擊第一個按鈕“建立新的功能”：
這里，“功能名稱”的值不像hotfix分支那樣需要考慮發布版本號的規則，可以用能夠清晰描述功能特征的文字。
創建完成后，SourceTree的項目目錄樹就出現了這個新分支，如下：
現在就可以在這個分支上修修補補了，經過一系列艱苦卓越的工作，這個功能開發完成了，就要合並到develop。功能分支只能合並到develop，為新的release分支做准備，
在SourceTree里，只要通過點擊“Gitflow”工具欄即可指導你完成：
“刪除分支”和“預覽”和上面hotfix分支里提到的效果是一樣，所不同的是，這里沒有“推送變更到遠程倉庫”的選項。有沒有這個選項的差別不大，可能是為了體現分支的推進的緊急程度吧。
合並完成后並將本地庫推送到遠端Github，這時看Github的分支關系網絡圖如下：
因為我在做的這個示例操作的時候，並沒有再對master分支進行過派生和合並，所以看到master的指示停在原地，后面並入develop的黑色分支既是功能分支。
release
所有特性的開發工作都是為了產品功能的更替，當一個或多個特性開發完成，可以進行發布了，就要准備創建release分支。
Release分支是為上線做准備的，它的命名也要遵守項目的版本命名規則，這個名字在最終合並到master時會自動變成版本標簽。
這個release分支也是測試工作的目標對象，，經過一系列艱苦卓越的測試、調整工作，這個release完成了，達到了可上線的狀態，就要合並到master和develop。
如圖“預覽”所示，這個release的名稱會自動成為master的標簽。
這一次，我有意沒有刪除這個分支，並把它推送到了Github，在Github上的分支關系網絡圖中，能夠明確地看到release的起點和終點，它最終被合並到了兩個“歷史性”分支中了。
收尾
三類臨時性分支中，hotfix和release的結果都要合並到master和develop中，為什么？因為它們的修改結果持續影響這后續的開發和維護，必須合並以保證代碼的一致性。
至此，SoureTree的Gitflow應用教程已經完成，如果你沒有認識到這個特性很有用，我只能說：好吧，你的開發工作還沒有復雜到一個程度，一個必須要規避代碼干擾、保證並行推進的程度。
對於小型項目和團隊來說，基於GIT的中心式協作模型和特性分支模型就足夠了；本協作模型適合中型、大型項目和團隊；對於更大型的團隊和項目來說，除了這個協作模型，還有一個交叉型協作模型可供管理使用。