痛！痛！痛！我們的好兄弟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修復。
開發流程如下：
- 最開始的時候我們創建好了master分支，然后基于master分支創建出了develop分支
- 然后A和B同時基于某個版本的develop分支拉出代碼進行開發，分支分別叫做feature-A和feature-B
- 如果開發過程中需要修復bug上線，那么就從master拉個分支出來，命名為hotfix-xxx進行修復，修復完成之后合并到develop和master，然后hotfix分支刪除
- 然后A代碼擼的比較快，先一步完成了開發，feature-A分支的代碼就合并到develop，feature分支被刪除，然后我們基于develop新建一個release-A分支進行測試
- 測試過程中如果發現問題那么我們就在release分支修復，把修復的代碼合并到develop去
- release-A一旦測試完成上線，就把代碼合并到master和develop，release分支被刪除
- 這時候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，如果接受之后就合并代碼部署了。
圖片來自Github官方PDF
具體可以看官方介紹。
這個方式簡單是簡單，但是在很多公司的業務開發過程中一般都有開發、測試、預發、生產幾個環境，沒有強有力的工具來支撐，我認為很難用這種簡單的模式來實現管理。
我覺得這種模式特別適合小團隊，人少，需求少，那就很容易了。
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?__biz=MzAxNDU0MTE0OA==&mid=2661008528&idx=1&sn=748c3b5bdaa28c3c7b3c06614fd69d47&scene=21#wechat_redirect
https://cloud.tencent.com/developer/article/1646937
本文轉載自微信公眾號「艾小仙」，可以通過以下二維碼關注。轉載本文請聯系艾小仙公眾號。
