簡(jiǎn)介
什么是gitflow？

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

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

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

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

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

我們來(lái)?yè)Q個(gè)角度來(lái)理解

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

主要分為兩大類(lèi)：

主分支(Main Branches)
輔助分支（supporting branches)
拓展開(kāi)來(lái)：

主分支： Master Develop

輔助分支：Feature、Release、Hotfix

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

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

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

來(lái)源只能是：hotfix和release分支。不能是其他分支。

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

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

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

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

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

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

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

hotfix只能從master上拉去，測(cè)試通過(guò)之后合并會(huì)master和develop

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

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