文章是正經文章，標題不要在意，哈哈
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