[[396899]]

Git作為現(xiàn)在主流的版本控制工具，但是如何在軟件開(kāi)發(fā)過(guò)程中進(jìn)行合理的分支管理是一個(gè)見(jiàn)仁見(jiàn)智的問(wèn)題。

接下來(lái)我會(huì)對(duì)比下現(xiàn)有的幾種比較普遍的分支管理方式和之前在阿里時(shí)候使用Aone的區(qū)別。

Git Flow

先看一張圖片，這張圖片來(lái)自Vincent在2010年提出的方案，完美的詮釋了Git Flow的工作模式。

作為已經(jīng)提出了10多年的模式，Git Flow相對(duì)來(lái)說(shuō)還算是比較簡(jiǎn)單的。

穩(wěn)定的分支就兩個(gè)：develop和master，這兩個(gè)分支是不會(huì)被刪除的，master對(duì)應(yīng)穩(wěn)定的版本，develop則是用于日常開(kāi)發(fā)的穩(wěn)定版本。

其他的feature、release、hotfix分支都是用完即刪。

feature分支是每個(gè)人的開(kāi)發(fā)分支，有新的需求都應(yīng)該基于develop拉出feature分支進(jìn)行開(kāi)發(fā)。

release分支則是用于測(cè)試和發(fā)布的分支。

hotfix用于緊急的bug修復(fù)。

開(kāi)發(fā)流程如下：

1. 最開(kāi)始的時(shí)候我們創(chuàng)建好了master分支，然后基于master分支創(chuàng)建出了develop分支
2. 然后A和B同時(shí)基于某個(gè)版本的develop分支拉出代碼進(jìn)行開(kāi)發(fā)，分支分別叫做feature-A和feature-B
3. 如果開(kāi)發(fā)過(guò)程中需要修復(fù)bug上線(xiàn)，那么就從master拉個(gè)分支出來(lái)，命名為hotfix-xxx進(jìn)行修復(fù)，修復(fù)完成之后合并到develop和master，然后hotfix分支刪除
4. 然后A代碼擼的比較快，先一步完成了開(kāi)發(fā)，feature-A分支的代碼就合并到develop，feature分支被刪除，然后我們基于develop新建一個(gè)release-A分支進(jìn)行測(cè)試
5. 測(cè)試過(guò)程中如果發(fā)現(xiàn)問(wèn)題那么我們就在release分支修復(fù)，把修復(fù)的代碼合并到develop去
6. release-A一旦測(cè)試完成上線(xiàn)，就把代碼合并到master和develop，release分支被刪除
7. 這時(shí)候B總算把需求開(kāi)發(fā)完了，然后也按照合并到develop，再新建release-B，合并到master和develop的過(guò)程來(lái)一遍

對(duì)于實(shí)際應(yīng)用也比較簡(jiǎn)單，對(duì)于Mac我們可以直接用最方便的方式進(jìn)行安裝。

首先，安裝Git Flow，brew install git-flow-avh，安裝好之后執(zhí)行g(shù)it flow init就會(huì)進(jìn)行初始化，可以輸入你的master和develop分支名字，然后設(shè)置其他幾個(gè)默認(rèn)分支的前綴。

然后執(zhí)行g(shù)it flow feature start irving就可以初始化創(chuàng)建一個(gè)feature分支進(jìn)行開(kāi)發(fā)，默認(rèn)我們可以看到是基于develop來(lái)創(chuàng)建的。

如果開(kāi)發(fā)完成，我們執(zhí)行命令git flow feature finish irving，然后我們的開(kāi)發(fā)分支就自動(dòng)合并到了develop，并且開(kāi)發(fā)分支已經(jīng)被刪除。

接著我們的分支需要提測(cè)和發(fā)布，執(zhí)行命令git flow release start irving，如果修復(fù)bug就直接在這上面修復(fù)。

測(cè)試完成之后，執(zhí)行命令git flow release finish irving，代碼將會(huì)被合并到master和develop，然后分支被刪除。

原理和實(shí)現(xiàn)方式都說(shuō)了，那么這個(gè)模式其實(shí)還是一樣的問(wèn)題，就是他比較適合固定版本的迭代開(kāi)發(fā)，對(duì)于互聯(lián)網(wǎng)不要臉的每天都要發(fā)版，每天10幾個(gè)需求都要上線(xiàn)來(lái)說(shuō)未免太難了。

develop分支我今天有10個(gè)需求，8個(gè)要上線(xiàn)，2個(gè)不上，代碼還有先后順序依賴(lài)之類(lèi)的，這就沒(méi)法玩好不好，但是他提供了一個(gè)比較好的規(guī)范和思路。

Github Flow

Github Flow可以說(shuō)非常簡(jiǎn)單了，它的提出是在2011年，主要就是針對(duì)Git Flow。

它就是基于master分支拉一個(gè)分支出來(lái)開(kāi)發(fā)，然后可以在新的分支中進(jìn)行開(kāi)發(fā)，完成之后提交pull request，如果接受之后就合并代碼部署了。

圖片來(lái)自Github官方PDF

具體可以看官方介紹。

這個(gè)方式簡(jiǎn)單是簡(jiǎn)單，但是在很多公司的業(yè)務(wù)開(kāi)發(fā)過(guò)程中一般都有開(kāi)發(fā)、測(cè)試、預(yù)發(fā)、生產(chǎn)幾個(gè)環(huán)境，沒(méi)有強(qiáng)有力的工具來(lái)支撐，我認(rèn)為很難用這種簡(jiǎn)單的模式來(lái)實(shí)現(xiàn)管理。

我覺(jué)得這種模式特別適合小團(tuán)隊(duì)，人少，需求少，那就很容易了。

Trunk-Based

這個(gè)模型提出的時(shí)間更晚一點(diǎn)，是在2013年P(guān)aul Hammant提出的方案。

看圖基本就能明白，這不就是SVN的模式嘛，主干trunk開(kāi)發(fā)，拉出新的分支進(jìn)行開(kāi)發(fā)部署、修復(fù)BUG。

用過(guò)的方案

我們之前用過(guò)一個(gè)方案，和Git Flow比較類(lèi)似，但是不依賴(lài)工具的支持，更多的是依靠團(tuán)隊(duì)本身的約定和規(guī)范。

對(duì)于開(kāi)發(fā)、測(cè)試、預(yù)發(fā)、生產(chǎn)分別使用分支develop、test、release、master分支，其中master分支作為穩(wěn)定分支，不能直接提交代碼，同時(shí)這幾個(gè)分支是固定唯一的分支。

首先開(kāi)發(fā)階段，大家都需要基于master創(chuàng)建最新的功能開(kāi)發(fā)分支，命名為feature/xxx。

如果需要發(fā)布到開(kāi)發(fā)環(huán)境，所有人的代碼都需要合并到develop，并且只能用develop分支進(jìn)行發(fā)布開(kāi)發(fā)環(huán)境。

如果開(kāi)發(fā)完成，需要提測(cè)的分支合并到test分支，那些還在開(kāi)發(fā)階段的就在develop好了。

測(cè)試完成之后需要發(fā)布預(yù)發(fā)(當(dāng)然叫灰度、uat都行)，就把代碼合并到release進(jìn)行發(fā)布。

發(fā)布完成之后，代碼自動(dòng)合并到master。

這樣做的好處就是首先規(guī)范了分支的開(kāi)發(fā)和管理，開(kāi)發(fā)中不會(huì)產(chǎn)生太多的糾紛，而且對(duì)于同時(shí)有多個(gè)需求開(kāi)發(fā)并且不同時(shí)間上線(xiàn)都可以做到很好的管理。

缺點(diǎn)就是一個(gè)項(xiàng)目多個(gè)需求開(kāi)發(fā)上線(xiàn)，需要合并多次代碼，從develop、teest到release都要分別合并一次代碼并且解決沖突。

總的來(lái)說(shuō)，這只是一個(gè)基于團(tuán)隊(duì)的規(guī)范，對(duì)于環(huán)境和中間件CI/CD能力沒(méi)有太多的要求，可以簡(jiǎn)單的套用在各個(gè)公司的場(chǎng)景。

阿里的解決方案

阿里的解決方案基本上可以說(shuō)是上面幾個(gè)模式的一個(gè)結(jié)合體，稱(chēng)作Aone Flow，可能因?yàn)楣ぞ弑旧砭徒凶鯝one吧。

分支只有3個(gè)，master分支、功能分支feature、發(fā)布分支release，其中release分支基本上是不需要開(kāi)發(fā)人員來(lái)參與管理的。

首先，分支的創(chuàng)建也都是基于master，如果有需求，首先創(chuàng)建一個(gè)feature分支，部署前Aone會(huì)自動(dòng)合并master代碼，所以不用操心代碼沒(méi)有合并的問(wèn)題，如果存在沖突需要手動(dòng)解決，反之則就自動(dòng)生成一個(gè)新的分支用于部署，這個(gè)分支就是release分支。

來(lái)自阿里云效

這個(gè)分支可以一直用來(lái)發(fā)布日常(理解成開(kāi)發(fā)或者測(cè)試環(huán)境合體)、預(yù)發(fā)和生產(chǎn)環(huán)境。

那如果多個(gè)需求同時(shí)在開(kāi)發(fā)有沖突不需要合并代碼嗎?首先，Aone部署可以同時(shí)部署多個(gè)分支，選擇部署多個(gè)功能分支代碼會(huì)自動(dòng)合并，如果存在沖突需要手動(dòng)解決，另外可以單獨(dú)建立一個(gè)環(huán)境來(lái)部署，互不影響，這個(gè)功能真是蠻吊的。

這個(gè)規(guī)則對(duì)于預(yù)發(fā)和生產(chǎn)環(huán)境也是同理。

整個(gè)開(kāi)發(fā)過(guò)程，我們不需要管各種分支，只需要一個(gè)feature功能分支用于發(fā)布各個(gè)環(huán)境，最終發(fā)布完成之后代碼自動(dòng)合并到master主分支(可選項(xiàng)，也可以不合并)。

整個(gè)模式看下來(lái)就是集成了各個(gè)模式的特點(diǎn)，參考了Git Flow的分支的特點(diǎn)，只不過(guò)其他的分支不用開(kāi)發(fā)人員關(guān)心，基于主干master拉出分支開(kāi)發(fā)，自動(dòng)合并又像是TrunkBased的做法，最終整個(gè)流程對(duì)于開(kāi)發(fā)人員體驗(yàn)下來(lái)又像是更簡(jiǎn)化版的Github Flow了。

文章參考：

http://www.brofive.org/?p=2165

https://mp.weixin.qq.com/s?__biz=MzAxNDU0MTE0OA==&mid=2661008528&idx=1&sn=748c3b5bdaa28c3c7b3c06614fd69d47&scene=21#wechat_redirect

https://cloud.tencent.com/developer/article/1646937

本文轉(zhuǎn)載自微信公眾號(hào)「艾小仙」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系艾小仙公眾號(hào)。