企業代碼版本管理之爭:TrunkBased vs GitFlow vs AoneFlow vs OneFlow vs ExeFlow

目錄

• 引言
• TrunkBased
• GitFlow
• AoneFlow
• OneFlow
• ExeFlow
• 綜述

引言

網絡上版本管理系統之爭持久而喧囂，依照聲量來說目前應該是Git佔了較大的優點。不過咱們本文的關注點在於代碼的分支管理模型，由於你們不管是用SVN或者Git，目的是爲了解決研發過程管理中的實際問題。我這裏整理幾種分支管理模型，這樣你們能夠對照本身的痛點選擇合適的模型。不過並非最靈活的方案就最好，靈活意味着分支的管理和具體研發學習曲線都更復雜。

我先根據實際生產過程當中企業面臨的問題列出一個清單：

• 學習曲線（Complexity）
  企業都但願研發團隊可以快投入生產，而在版本管理這種「小事」不要花費太多精力。
• 需求變動（Release）
  企業在一個迭代過程當中是否可以徹底不進行需求的變動，不管大家的週期是兩週、一個月、或者一季度。
• 線上修正（Hotfix）
  系統目前是否已經很是穩定，不存在須要發佈線上修正的可能。
• 多環境（CI/CD）
  企業是否存在多環境的要求（測試、預發佈、正式等）
• 長期需求（Long-Lived Version-control Story）
  企業是否存在一個大需求可能要持續數個迭代。（例如底層的基礎業務模型擴展，增長新的數據隔離標識字段，涉及到系統底層或者全系統業務邏輯的變動。這裏列這種需求並非說必須支持，有些普通需求因爲錯誤的技術方案/市場的變化等狀況就會變化成這樣的需求，因此綜合考慮邊界狀況。）

另外也交代一下我所在的公司背景：
咱們是一家企業內部學習培訓的人力資源SAAS管理平臺，對於平臺改進有本身的規劃和目標，可是又面臨着大客戶的定製化需求以及交付時間壓力。技術棧仍是Java和.Net 雙棧並存，因此能夠說是最複雜的研發環境了。咱們也慢慢衍生出了本身的一套改進的代碼版本管理模型。

TrunkBased

原理¹：研發團隊在名稱爲 Trunk 的單一分支進行開發，當開發工做到必定階段的時候達到可發佈條件後，切出Release分支進行發佈，而且Release分支是不能夠修改的僅僅作發佈使用。大部分SVN用戶是基於本模型進行開發。
適合小團隊的模型，你們都直接在Trunk上進行開發

適合較大團隊的模型，你們切出短時間的特性分支進行開發，完成後合併回Trunk。

適用場景：適合於單一穩定產品線，迭代排期穩定，需求邊界徹底可控的團隊。
優勢：模型簡單
缺點：

• 線上修正：按照上圖目前系統已經發布了12.1，下一個迭代也在開發中，線上發現了問題。因爲Release分支是禁止修改的，而Trunk此時包含了新的特性代碼沒法發佈，就形成了線上異常沒法修復。
• 需求變動：沒法支持，已經提交到Trunk的內容抽離很困難。
• 多環境：沒法支持
• 長期需求：沒法支持

總結：Trunk Based最大的優點就是清晰簡單，付出的代價就是靈活性，基本能夠說不存在任何靈活性。適用的場景我以爲是進入到後期維護的大型系統，不會作太多的變動而且不會有太多的突發問題。

GitFlow

GitFlow來源應該是 Vincent Driessen 在2010年1月發表的這篇《A successful Git branching model》，基本是如今Git中最出名的流程管理方法了。

這張圖相信你們都不陌生。
原理：
主要分爲5個分支

• master分支存放全部正式發佈的版本，能夠做爲項目歷史版本記錄分支，不直接提交代碼。僅用於保持一個對應線上運行代碼的 code base。
• develop分支爲主開發分支，通常不直接提交代碼
• feature分支爲新功能分支，feature分支都是基於develop建立的，開發完成後會合併到develop分支上。同時存在多個
• release分支基於最新develop分支建立，當新功能足夠發佈一個新版本(或者接近新版本發佈的截止日期)，從develop分支建立一個release分支做爲新版本的起點，用於測試，全部的測試bug在這個分支改。測試完成後合併到master並打上版本號，同時也合併到develop，更新最新開發分支。(一旦打了release分支以後不要從develop分支上合併新的改動到release分支)，同一時間只有1個，生命週期很短，只是爲了發佈。
• hotfix分支基於master分支建立，對線上版本的bug進行修復，完成後直接合併到master分支和develop分支，若是當前還有新功能release分支，也同步到release分支上。同一時間只有1個，生命週期較短。
  適用場景：處於前中期的大型項目，人員較多管理場景較複雜，可是迭代相對穩定，週期內不會頻繁的變動需求，儘可能不要開長需求分支。
  優勢：
  可以支持線上修正、多環境
  缺點：
• 複雜度稍高
• 需求變動：不夠靈活，因爲主分支其實是基於develop，那意味着一旦代碼提交上去，一段時間後須要撤銷（本次迭代不發佈）就比較困難

總結：Gitflow已經很偏向互聯網風格的代碼管理，考慮到了多環境、線上修正。並且如今不少IDE或者工具備整合了GitFlow的插件使用起來會更簡單。對於有良好規劃和進度控制的項目，應該是已經夠用了。可是對於一些有交付日期的，可是需求池能夠調整的項目可能還不夠靈活。

AoneFlow

阿里的研發效能事業部專家基於TrunkBased和GitFlow提出了一套新思路：AoneFlow。
原理：AoneFlow 只使用三種分支類型：主幹分支、特性分支、發佈分支，以及三條基本規則。

1. 開始工做前，從主幹建立特性分支。
   

2. 經過合併特性分支，造成發佈分支。
   

3. 發佈到線上正式環境後，合併相應的發佈分支到主幹，在主幹添加標籤，同時刪除該發佈分支關聯的特性分支。
   

缺點：

• 複雜度稍高
• 多環境：因爲沒有develop分支因此可能測試環境構建會有一些問題。
  優勢：
• 線上環境，長期需求都是支持的

總結：AoneFlow最重要的點，就是保證master分支可用和隨時可發佈，其餘可能都是臨時分支。因此取名的時候應該是Ali-One-Flow，這個含義。臨時分支的組裝就有不少種玩法了，須要企業根據本身的須要來定製處理。

OneFlow

OneFlow我找到兩個版本，一個是國內版本，一個是國外的版本。
國內版本：
原理：此模式是TrunkBased的升級版，增長了Hotfix分支，採用多主幹模式，通常是雙主幹（一個主幹分支+一個主幹發佈分支）。OneFlow在TrunkBased模式演進中，作了一此改善，分離了主幹分支和發佈分支，有效的規避了一些問題。可是一樣還不能知足多版本，多產品的並行開發。
國外版本：
原理：此模式是GitFlow的簡化版本，可是（做者認爲）並不比GitFlow遜色。主要也就是雙分支²，除了主幹分支，只會額外保持一個分支，在不一樣的階段切除特性、發佈、修正分支

並且還提供了變種版本，master+develop 雙主幹分支的模式。

總結：國外版本的OneFlow發表在2017年，我以爲他肯定了基於一個，最多兩個的固定分支進行開發這種原則。提供了企業版本管理過程當中的最佳實踐原則，（我以爲）也啓發了AoneFlow這種優秀的Flow。

ExeFlow

ExeFlow是咱們公司目前在使用的代碼管理流程的名稱，主要是吸收了AoneFlow的思想，同時根據咱們本身的環境進行一些流程和分支的固化。
要理解這個Flow流程，首先基於咱們的實際工做場景：
咱們的系統因爲主要是面向大型企業內部使用，存在複雜的分發流程和權限控制，通過長時間的累積業務模型也很複雜各類關聯和引用，因此有一些大型任務的開發週期可能會比較長，到達2-3個月的週期。
咱們的迭代週期正常是1個月。流程大概以下：

• 上月末進行迭代計劃評估與安排，這裏會確認下月迭代目標的Story內容與數據。各自主管進行子任務的拆分評估與排期。
• 開發時間通常是2周，咱們基本是會在月中設定研發截止線，全部研發任務要在截止線前完成提測。期間有完成的任務能夠隨時提測。【涉及分支：Feature，Local，Develop】
• 完整的系統集成測試時間通常是安排在第三週，測試會進行全面的測試。本週研發的主要任務一方面是處理Bug，一方面能夠介入下月迭代大項的需求說明與分析。【涉及分支：Feature，Local，Develop】
• 第四周的前三天，咱們會切出預發佈的分支在第四周週一時，會給出明確本次可以上線的Story List，不在清單內的都不容許合併只預發佈環境（也就是咱們實際上運行需求在預發佈以前仍舊有變動，只要測試人員經過了集成測試環境，就能夠合併而且發佈），本次發版的具體內容和通知也是當天發出。【涉及分支：Feature，Release】
• 發版通常安排在當月的最後一個週四（爲了防止有線上問題，因此不能是週五次日會沒有人員值守）。【涉及分支：Release，Master】

主要經歷了2個大版本的變化
版本1，基本是參考GitFlow

這個版本的固定獨立分支是三條：Master，Develop，Local。核心在於Release分支仍是由Develop創建，對於需求變動的支持性不夠靈活。

版本2，是參考AoneFlow

（上圖就是使用gitgraphjs繪製的）
這個版本的固定獨立分支也仍是是三條：Master，Develop，Local。
可是核心差別在於Release分支是由Master創建，而且合併須要上線的Feature分支，而Release分支在咱們企業的流程中只會存在2-3天的時間。

總結：實際上是比較複雜的流程，並且研發的操做的內容實際更多。咱們還要鎖定某些分支，設定權限管理。可是解決了咱們的問題，因此從上到下都能替換到複雜流程帶來的好處。

綜述

若是你完整看完了這篇文章，實際上如今須要的並非立刻選擇當前企業應該選用哪種Flow管理模型，而是認真的思考企業實際面臨的問題和痛點。越靈活的流程越複雜，對於研發人員初期的接收難度就越高。咱們想真正讓研發團隊理解並接受某個管理模型，最重要的是這個東西解決了企業面臨的問題。才能讓管理層、研發自身體會到好處。
我看了不少版本管理軟件的對比，不管是擡Svn打Git或者反之，我以爲都對也都不對。由於不管管理或者技術，自己沒有對錯優劣，問題是場景。若是一個簡單穩定的後期維護項目，強推複雜的管理流程，效果不會好，由於沒有解決任何問題，只會引入問題。
管理的核心在於解決問題，而不是管理行爲自己。

---

1. 引用自Trunk Based Development Introduction↩

2. 畫圖工具是使用gitgraphjs↩