[[396899]]

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

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

Git Flow

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

作為已經(jīng)提出了10多年的模式，Git Flow相對來說還算是比較簡單的。

穩(wěn)定的分支就兩個：develop和master，這兩個分支是不會被刪除的，master對應穩(wěn)定的版本，develop則是用于日常開發(fā)的穩(wěn)定版本。

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

feature分支是每個人的開發(fā)分支，有新的需求都應該基于develop拉出feature分支進行開發(fā)。

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

hotfix用于緊急的bug修復。

開發(fā)流程如下：

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

對于實際應用也比較簡單，對于Mac我們可以直接用最方便的方式進行安裝。

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

然后執(zhí)行git flow feature start irving就可以初始化創(chuàng)建一個feature分支進行開發(fā)，默認我們可以看到是基于develop來創(chuàng)建的。

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

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

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

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

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

Github Flow

Github Flow可以說非常簡單了，它的提出是在2011年，主要就是針對Git Flow。

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

圖片來自Github官方PDF

具體可以看官方介紹。

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

我覺得這種模式特別適合小團隊，人少，需求少，那就很容易了。

Trunk-Based

這個模型提出的時間更晚一點，是在2013年Paul Hammant提出的方案。

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

用過的方案

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

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

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

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

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

測試完成之后需要發(fā)布預發(fā)(當然叫灰度、uat都行)，就把代碼合并到release進行發(fā)布。

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

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

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

總的來說，這只是一個基于團隊的規(guī)范，對于環(huán)境和中間件CI/CD能力沒有太多的要求，可以簡單的套用在各個公司的場景。

阿里的解決方案

阿里的解決方案基本上可以說是上面幾個模式的一個結合體，稱作Aone Flow，可能因為工具本身就叫做Aone吧。

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

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

來自阿里云效

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

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

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

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

整個模式看下來就是集成了各個模式的特點，參考了Git Flow的分支的特點，只不過其他的分支不用開發(fā)人員關心，基于主干master拉出分支開發(fā)，自動合并又像是TrunkBased的做法，最終整個流程對于開發(fā)人員體驗下來又像是更簡化版的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)載自微信公眾號「艾小仙」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系艾小仙公眾號。