簡介
什么是gitflow？

我們大家都很會用git，但是我們很少去關心我們要怎么用branch和版本控制。

只知道master是第一個主分支，其他分支都是次要分支， 那你知道如下的問題如何回答嗎？

如何保證主分支的穩定性？
如何開發新的feature？
如何創建分支名稱？分支多了如何管理？如何知道每個分支干嘛的呢？
哪些分支合并了？
哪些分支是release的分支？可以穩定使用的？
如果穩定分支代碼出現沒有測出來的bug，如何創建分支快速修復？
這個就像寫代碼，要有個規范一樣， 當然我們可以不按照規范來做，git同樣能處理。但是定義一個科學的操作規范，往往能讓效率事半功倍。

gitflow 是一種git分支模型，是由創始人Vincent Driessen 2010年創建的。這只是一種建議，在團隊合作中，具體項目中要靈活應用，不用可守成規，覺得不合理的地方可以自行修正。

gitflow 流程圖
我們來看下創始人最初的流程圖：

我們來換個角度來理解

gitflow的核心要素是branch，通過branch來實現工作流。

主要分為兩大類：

主分支(Main Branches)
輔助分支（supporting branches)
拓展開來：

主分支： Master Develop

輔助分支：Feature、Release、Hotfix

gitflow工作流如何使用
剛開始的時候，我們有個master分支，我們要基于master來創建develop

master
master分支上存放的是最穩定的版本，并且該分支的代碼是隨時可以讓用戶使用的代碼，就是非常非常穩定的代碼。當一個版本開發完成之后，交付給客戶的時候，master上面的額代碼也要被更新。同時，每次更新都要打上相應的tag。

任何人不允許在master上進行代碼的直接push提交，只接受其他分支合入。原則上master分支必須是release的分支合過來的代碼。

來源只能是：hotfix和release分支。不能是其他分支。

master一定是經過多輪測試，但是不能保證完全沒有bug，所以引入hotfix分支，來修復未知bug

develop
develop是主開發分支，這個分支上被合并的代碼始終是下一個版本需要加入的feature。這個分支可以合并一些feature。當要release的時候，就從這個分支上進行創建release分支。

合并到develop分支上的必須保證功能完整，不影響develop分支的正常運行。

feature
feature 分支又叫功能分支，一般命名方法feature/xxx，用來開發版本或者未來要發布新的功能或者探索新功能。（feature 分支功能要保證里面的commit 的粒度要非常細，避免和主分支脫節嚴重，應該大功能切成一個一個小功能來merge，而不是一次merge一個大的）

Release
這個分支又叫預發布分支，一般命名為 release/1.1.x 這個分支轉為發布做準備。允許小量級的bug修復。

release分支只能從develop分支拉過來，用來修復一些bug。（不做feature相關的開發）

hotfix
hotfix 叫熱修復分支，一般命名為hotfix/4.1.3 為固定某個版本進行修復，當master上遇到嚴重問題需要修復的時候，就要從master上指定tag拉取。這樣做就是為了隔離feature開發和bug修復。

hotfix只能從master上拉去，測試通過之后合并會master和develop

總結
有些人覺得gitflow好用，有些人覺得gitflow太死板，太復雜，團隊里面每個人都要遵守這套規則，會很麻煩。畢竟規則越復雜，用起來越難。所以創始人也建議團隊根據實際情況調整策略。我覺得有以下幾點值得注意：

團隊主要成員如果成員固定，并且訓練有素，可以考慮用一下。團隊人員如果太多，太雜，不建議。如果主要團隊人員就1-2個人，也不建議。
從時間點上來說，要將團隊統一戰線，比如master要開始release了，整個團隊需要切到release分支去修復bug，并且堅決不允許有feature合入。大feature可以下一個版本進行合并。
release要全部測試人員測試完成，沒有bug了，再合到master上。
一定要保證master上面的有個穩定的代碼源（這個是最重要的一點，如果達不到，產品化效果會很差）
不同的團隊保持并行開發，相互之間干擾要降到最低。
沒有比較完善的測試團隊，不建議用，因為如果不能保證master分支上的代碼足夠穩定，在修復bug的時候，要頻繁hotfix到master和develop以及release上，如果過多，這個是比較恐怖的事情。