痛！痛！痛！咱們的好兄弟Git，一路走好！

文章是正經文章，標題不要在乎，哈哈

Git做爲如今主流的版本控制工具，可是如何在軟件開發過程當中進行合理的分支管理是一個見仁見智的問題。

接下來我會對比下現有的幾種比較廣泛的分支管理方式和以前在阿里時候使用Aone的區別。

Git Flow

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

做爲已經提出了10多年的模式，Git Flow相對來講還算是比較簡單的。

穩定的分支就兩個：develop和master，這兩個分支是不會被刪除的，master對應穩定的版本，develop則是用於平常開發的穩定版本。

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

feature分支是每一個人的開發分支，有新的需求都應該基於develop拉出feature分支進行開發。

release分支則是用於測試和發佈的分支。

hotfix用於緊急的bug修復。

開發流程以下：

1. 最開始的時候咱們建立好了master分支，而後基於master分支建立出了develop分支
2. 而後A和B同時基於某個版本的develop分支拉出代碼進行開發，分支分別叫作feature-A和feature-B
3. 若是開發過程當中須要修復bug上線，那麼就從master拉個分支出來，命名爲hotfix-xxx進行修復，修復完成以後合併到develop和master，而後hotfix分支刪除
4. 而後A代碼擼的比較快，先一步完成了開發，feature-A分支的代碼就合併到develop，feature分支被刪除，而後咱們基於develop新建一個release-A分支進行測試
5. 測試過程當中若是發現問題那麼咱們就在release分支修復，把修復的代碼合併到develop去
6. release-A一旦測試完成上線，就把代碼合併到master和develop，release分支被刪除
7. 這時候B總算把需求開發完了，而後也按照合併到develop，再新建release-B，合併到master和develop的過程來一遍

對於實際應用也比較簡單，對於Mac咱們能夠直接用最方便的方式進行安裝。

首先，安裝Git Flow，brew install git-flow-avh，安裝好以後執行git flow init就會進行初始化，能夠輸入你的master和develop分支名字，而後設置其餘幾個默認分支的前綴。

而後執行git flow feature start irving就能夠初始化建立一個feature分支進行開發，默認咱們能夠看到是基於develop來建立的。

若是開發完成，咱們執行命令git flow feature finish irving，而後咱們的開發分支就自動合併到了develop，而且開發分支已經被刪除。

接着咱們的分支須要提測和發佈，執行命令git flow release start irving，若是修復bug就直接在這上面修復。

測試完成以後，執行命令git flow release finish irving，代碼將會被合併到master和develop，而後分支被刪除。

原理和實現方式都說了，那麼這個模式其實仍是同樣的問題，就是他比較適合固定版本的迭代開發，對於互聯網不要臉的天天都要發版，天天10幾個需求都要上線來講未免太難了。

develop分支我今天有10個需求，8個要上線，2個不上，代碼還有前後順序依賴之類的，這就無法玩好很差，可是他提供了一個比較好的規範和思路。

Github Flow

Github Flow能夠說很是簡單了，它的提出是在2011年，主要就是針對Git Flow。

它就是基於master分支拉一個分支出來開發，而後能夠在新的分支中進行開發，完成以後提交pull request，若是接受以後就合併代碼部署了。

具體能夠看官方介紹。

這個方式簡單是簡單，可是在不少公司的業務開發過程當中通常都有開發、測試、預發、生產幾個環境，沒有強有力的工具來支撐，我認爲很難用這種簡單的模式來實現管理。

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

Trunk-Based

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

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

用過的方案

咱們以前用過一個方案，和Git Flow比較相似，可是不依賴工具的支持，更多的是依靠團隊自己的約定和規範。

對於開發、測試、預發、生產分別使用分支develop、test、release、master分支，其中master分支做爲穩定分支，不能直接提交代碼，同時這幾個分支是固定惟一的分支。

首先開發階段，你們都須要基於master建立最新的功能開發分支，命名爲feature/xxx。

若是須要發佈到開發環境，全部人的代碼都須要合併到develop，而且只能用develop分支進行發佈開發環境。

若是開發完成，須要提測的分支合併到test分支，那些還在開發階段的就在develop好了。

測試完成以後須要發佈預發(固然叫灰度、uat都行)，就把代碼合併到release進行發佈。

發佈完成以後，代碼自動合併到master。

這樣作的好處就是首先規範了分支的開發和管理，開發中不會產生太多的糾紛，並且對於同時有多個需求開發而且不一樣時間上線均可以作到很好的管理。

缺點就是一個項目多個需求開發上線，須要合併屢次代碼，從develop、teest到release都要分別合併一次代碼而且解決衝突。

總的來講，這只是一個基於團隊的規範，對於環境和中間件CI/CD能力沒有太多的要求，能夠簡單的套用在各個公司的場景。

阿里的解決方案

阿里的解決方案基本上能夠說是上面幾個模式的一個結合體，稱做Aone Flow，可能由於工具自己就叫作Aone吧。

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

首先，分支的建立也都是基於master，若是有需求，首先建立一個feature分支，部署前Aone會自動合併master代碼，因此不用操心代碼沒有合併的問題，若是存在衝突須要手動解決，反之則就自動生成一個新的分支用於部署，這個分支就是release分支。

這個分支能夠一直用來發布平常(理解成開發或者測試環境合體)、預發和生產環境。

那若是多個需求同時在開發有衝突不須要合併代碼嗎？首先，Aone部署能夠同時部署多個分支，選擇部署多個功能分支代碼會自動合併，若是存在衝突須要手動解決，另外能夠單獨創建一個環境來部署，互不影響，這個功能真是蠻吊的。

這個規則對於預發和生產環境也是同理。

整個開發過程，咱們不須要管各類分支，只須要一個feature功能分支用於發佈各個環境，最終發佈完成以後代碼自動合併到master主分支（可選項，也能夠不合並）。

整個模式看下來就是集成了各個模式的特色，參考了Git Flow的分支的特色，只不過其餘的分支不用開發人員關心，基於主幹master拉出分支開發，自動合併又像是TrunkBased的作法，最終整個流程對於開發人員體驗下來又像是更簡化版的Github Flow了。

文章參考：

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

https://mp.weixin.qq.com/s?__...

https://cloud.tencent.com/dev...