簡介
什么是gitflow？

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

只知道m(xù)aster是第一個(gè)主分支，其他分支都是次要分支， 那你知道如下的問題如何回答嗎？

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

gitflow 是一種git分支模型，是由創(chuàng)始人Vincent Driessen 2010年創(chuàng)建的。這只是一種建議，在團(tuán)隊(duì)合作中，具體項(xiàng)目中要靈活應(yīng)用，不用可守成規(guī)，覺得不合理的地方可以自行修正。

gitflow 流程圖
我們來看下創(chuàng)始人最初的流程圖：

我們來換個(gè)角度來理解

gitflow的核心要素是branch，通過branch來實(shí)現(xiàn)工作流。

主要分為兩大類：

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

主分支： Master Develop

輔助分支：Feature、Release、Hotfix

gitflow工作流如何使用
剛開始的時(shí)候，我們有個(gè)master分支，我們要基于master來創(chuàng)建develop

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

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

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

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

develop
develop是主開發(fā)分支，這個(gè)分支上被合并的代碼始終是下一個(gè)版本需要加入的feature。這個(gè)分支可以合并一些feature。當(dāng)要release的時(shí)候，就從這個(gè)分支上進(jìn)行創(chuàng)建release分支。

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

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

Release
這個(gè)分支又叫預(yù)發(fā)布分支，一般命名為 release/1.1.x 這個(gè)分支轉(zhuǎn)為發(fā)布做準(zhǔn)備。允許小量級的bug修復(fù)。

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

hotfix
hotfix 叫熱修復(fù)分支，一般命名為hotfix/4.1.3 為固定某個(gè)版本進(jìn)行修復(fù)，當(dāng)master上遇到嚴(yán)重問題需要修復(fù)的時(shí)候，就要從master上指定tag拉取。這樣做就是為了隔離feature開發(fā)和bug修復(fù)。

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

總結(jié)
有些人覺得gitflow好用，有些人覺得gitflow太死板，太復(fù)雜，團(tuán)隊(duì)里面每個(gè)人都要遵守這套規(guī)則，會很麻煩。畢竟規(guī)則越復(fù)雜，用起來越難。所以創(chuàng)始人也建議團(tuán)隊(duì)根據(jù)實(shí)際情況調(diào)整策略。我覺得有以下幾點(diǎn)值得注意：

團(tuán)隊(duì)主要成員如果成員固定，并且訓(xùn)練有素，可以考慮用一下。團(tuán)隊(duì)人員如果太多，太雜，不建議。如果主要團(tuán)隊(duì)人員就1-2個(gè)人，也不建議。
從時(shí)間點(diǎn)上來說，要將團(tuán)隊(duì)統(tǒng)一戰(zhàn)線，比如master要開始release了，整個(gè)團(tuán)隊(duì)需要切到release分支去修復(fù)bug，并且堅(jiān)決不允許有feature合入。大feature可以下一個(gè)版本進(jìn)行合并。
release要全部測試人員測試完成，沒有bug了，再合到master上。
一定要保證master上面的有個(gè)穩(wěn)定的代碼源（這個(gè)是最重要的一點(diǎn)，如果達(dá)不到，產(chǎn)品化效果會很差）
不同的團(tuán)隊(duì)保持并行開發(fā)，相互之間干擾要降到最低。
沒有比較完善的測試團(tuán)隊(duì)，不建議用，因?yàn)槿绻荒鼙ＷCmaster分支上的代碼足夠穩(wěn)定，在修復(fù)bug的時(shí)候，要頻繁hotfix到master和develop以及release上，如果過多，這個(gè)是比較恐怖的事情。