https://blog.csdn.net/u011904605/article/details/53224420

我說的以下流程，sourceTree等工具已經完美的支援了，滑鼠點兩下就完成了。簡直是完美。

簡介

Feature Branch Workflow是一種非常靈活的開發方式。對於一些規模比較大的團隊，最好就是給特定的分支賦予不同的角色。除了功能分支(feature branch)，Gitflow Workflow還使用獨立的分支來準備釋出(preparing)，維護(maintaining), 和記錄版本(recording releases)。

分支型別和流程

下圖能說明整個流程，只要你看得懂的話。該模式來自 

• feature（多個、玫紅）。主要是自己玩了，差不多的時候要合併回develop去。從不與master互動。
• develop（1個、黃色）。主要是和feature以及release互動。
• release（同一時間1個、綠色）。總是基於develop，最後又合併回develop。當然對應的tag跑到master這邊去了。生命週期很短，只是為了釋出
• hotfix（同一時間1個、紅色）。總是基於master，並最後合併到master和develop。生命週期較短，用了修復bug或小粒度修改釋出。
• master（1個藍色）。沒有什麼東西，僅是一些關聯的tag，因從不在master上開發。

在這個模型中，master和develop都具有象徵意義。master分支上的程式碼總是穩定的（stable build），隨時可以釋出出去。develop上的程式碼總是從feature上合併過來的，可以進行Nightly Builds，但不直接在develop上進行開發。當develop上的feature足夠多以至於可以進行新版本的釋出時，可以建立release分支。

release分支基於develop，進行很簡單的修改後就被合併到master，並打上tag，表示可以釋出了。緊接著release將被合併到develop；此時develop可能往前跑了一段，出現合併衝突，需要手工解決衝突後再次合併。這步完成後就刪除release分支。

當從已釋出版本中發現bug要修復時，就應用到hotfix分支了。hotfix基於master分支，完成bug修復或緊急修改後，要merge回master，打上一個新的tag，並merge回develop，刪除hotfix分支。

由此可見release和hotfix的生命週期都較短，master/develop雖然總是存在但卻不常使用。

分支詳解

主分支 （Historical Branches）

主分支是所有開發活動的核心分支。所有的開發活動產生的輸出物最終都會反映到主分支的程式碼中。主分支分為master分支和development分支。

master 分支

master分支上存放的應該是隨時可供在生產環境中部署的程式碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的程式碼時，master分支上的程式碼會被更新。同時，每一次更新，最好新增對應的版本號標籤（TAG）。

develop分支

develop分支是儲存當前最新開發成果的分支。通常這個分支上的程式碼也是可進行每日夜間釋出的程式碼（Nightly build）。因此這個分支有時也可以被稱作整合分支（integration branch）。

輔助分支

輔助分支是用於組織解決特定問題的各種軟體開發活動的分支。輔助分支主要用於組織軟體新功能的並行開發、簡化新功能開發程式碼的跟蹤、輔助完成版本釋出工作以及對生產程式碼的缺陷進行緊急修復工作。這些分支與主分支不同，通常只會在有限的時間範圍記憶體在。

輔助分支包括：

1. 用於開發新功能時所使用的feature分支；
2. 用於輔助版本釋出的release分支；
3. 用於修正生產程式碼中的缺陷的hotfix分支。

以上這些分支都有固定的使用目的和分支操作限制。從單純技術的角度說，這些分支與Git其他分支並沒有什麼區別，但通過命名，我們定義了使用這些分支的方法。

feature 分支

使用規範：

1. 可以從develop分支發起feature分支
2. 程式碼必須合併回develop分支
3. feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱

feature分支（有時也可以被叫做“topic分支”）通常是在開發一項新的軟體功能的時候使用，這個分支上的程式碼變更最終合併回develop分支或者乾脆被拋棄掉（例如實驗性且效果不好的程式碼變更）。

release分支（preparing）

使用規範：

• 可以從develop分支派生
• 必須合併回develop分支和master分支
• 分支命名慣例：release-*

release分支是為釋出新的產品版本而設計的。在這個分支上的程式碼允許做小的缺陷修正、準備釋出版本所需的各項說明資訊（版本號、釋出時間、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閒出來以接受新的feature分支上的程式碼提交，進入新的軟體開發迭代週期。

當develop分支上的程式碼已經包含了所有即將釋出的版本中所計劃包含的軟體功能，並且已通過所有測試時，我們就可以考慮準備建立release分支了。而所有在當前即將釋出的版本之外的業務需求一定要確保不能混到release分支之內（避免由此引入一些不可控的系統缺陷）。

成功的派生了release分支，並被賦予版本號之後，develop分支就可以為“下一個版本”服務了。所謂的“下一個版本”是在當前即將釋出的版本之後釋出的版本。版本號的命名可以依據專案定義的版本號命名規則進行。

hotfix分支（maintaining）

使用規範：

• 可以從master分支派生
• 必須合併回master分支和develop分支
• 分支命名慣例：hotfix-*

除了是計劃外建立的以外，hotfix分支與release分支十分相似：都可以產生一個新的可供在生產環境部署的軟體版本。

當生產環境中的軟體遇到了異常情況或者發現了嚴重到必須立即修復的軟體缺陷的時候，就需要從master分支上指定的TAG版本派生hotfix分支來組織程式碼的緊急修復工作。

這樣做的顯而易見的好處是不會打斷正在進行的develop分支的開發工作，能夠讓團隊中負責新功能開發的人與負責程式碼緊急修復的人並行的開展工作。

問題

管理衝突

1. 多個Feature 分支開發完成，提交到develop 分支時，修改了共同的模組。
2. release 分支或者hotfix 分支修改了bug合併回develop時，發現develop分支已經往前面走了一截。

在執行可能有衝突的操作前，先檢視一下 暫存區 和 工作目錄，保證其中沒有修改。

比如使用git stash就可以把暫存區 和 工作目錄的修改儲存起來，讓暫存區 和 工作目錄處於乾淨的狀態。

更進一步

Gitflow workflow 和pull request 組合起來使用，程式碼審查機制的加入，會讓這個模式大放異彩。下一篇文章中， 我會詳細介紹 程式碼審查