這次學委講講開源項目的分支管理，幫助讀者了解開源項目是怎麼管理代碼的。
多數開源項目都是main（以前是master/trunk）分支管理代碼的。
開發版本或者中間修訂版本走feature 分支釋出，然後再定期合并到master 分支。
分支管理是什麼
分支管理，簡單了解，就是多條生産線管理，比如一款手機的多個版本的生産。
比如某個手機的三條生産線：
現售的Mate30手機，在裝訂生産。
同時還有Mate20舊版本還有部分銷售訂單還在繼續裝訂。
新版本Mate40還在研發
這樣就好了解，我們的項目代碼就是制作手機的輸入，通過管理多個分支，讓不同産品線團隊做到最大程度的獨立開發，釋出不同款式産品。
下面介紹一下著名開源項目和我們做開源項目應該怎麼進行分支管理的
第一種 基于主幹分支管理（Trunk Based）比如LINUX核心
我們打開Linux核心的主線repo，看到如下的分支，隻有master主幹分支。
非常簡單，也比較典型的主幹為中心的分支管理。
因為linux核心主線隻有一個，新的特性代碼會被不斷送出到主線，新核心也沒有必要支援向後移植。
如果需要得用指定的tag來檢出特定版本分支，進行修訂發行。
就像下圖一樣，以trunk分支為中心，每一個彎都是一個PR（Pull Request），合并到trunk分支。
學委補充一下PR，PR代表每次有效開發工作的送出與合并。
主幹分支管理的好壞：
好處：簡化管理，所有特性隻要稽核通過馬上合并到主幹分支。這樣随時可以釋出，也避免了出現大規模內建的風險。
缺點：一個個單一的送出造成問題不大，不過當出現颠覆式的送出或者多個送出，這些送出造成的問題會一直影響主幹分支，也影響到每次釋出，直到問題解決。
小夥伴可能有疑問了，那麼穩定發行版本，如何進行打更新檔（比如遇到bug或者安全漏洞需要送出修改）
穩定版本倉庫：
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/linux還有一個獨立的stable 倉庫，它基于主線分支的一次鏡像（或者定期同步，主要是發行大版本的時候）。
确定了發行的主版本後，做一個分支釋出為stable倉庫，後續比較急的更新檔都打在stable分支上，然後再回顧這些送出，釋出到核心倉庫的主幹分支。
第二種 Gitflow模式，即多特性分支管理, 比如hadoop
大資料的底層hadoop架構是怎麼發行的？
我們看看下圖，這就一目了然了。
一個trunk主幹分支，加上現行的主流版本的特性分支（branch-2.10， branch-3.2等）。
别看有trunk分支就是咬定了是trunk-based開發模式，我們要看這個産品活躍分支。
hadoop架構誕生很早，應用比較廣泛，屬于應用型上層架構。
很多企業用的版本都不是統一個的3.X新版本，不少企業還是2.X版本。是以hadoop社群采用這種分支管理模式，長期維護了多個主流版本的開發。這點學委覺得是非常合适的。
就像下圖一樣，每一個彎都是一個PR（Pull Request）：
學委想指出，這裡出現了多個長分支，像feature1.x, feature
2.x(當然hadoop現在不維護1.x版本了），這個圖隻是展示作用。
這樣的好處：
各個分支的開發獨立運作，hadoop 2.X項目主要還是基于Java7運作環境執行。而hadoop 3.X 跟Java8運作。
這樣提高了不同分支的獨立行，兼顧發行效率。畢竟java7跟java8有不少差別的。
壞處最關鍵的就是：合并的風險！
随着時間發展，這些大分支積累的patch和主幹分支積累的新開發特性，總需要一個時間合并起來，這時候需要很多工作進行合并校對應對一個相對大的工程。
這些大量代碼合并往往需要配套不止內建測試，還有回歸測試。（當然主幹分支需要這套，但是主幹分支可以儲存每天測完，這個是多分支管理無法比拟的）
延伸 - 自己的項目該如何選擇？
非常簡單，如果是個人開發者，直接走TBD（Trunk Based Development）。比較簡單，随時可以打一個tag，釋出一個版本。
如果是一個百人團隊，那麼學委建議根據實際考慮了。
統一業務平台（二開或者傳統大型平台）多團隊多項目開發，建議走Git Flow(feature branch模式）多分支模式開發，保證各個項目團隊的獨立性，同時縮短定期合并的周期。
微服務多元件的單個平台，可以走TBD，劃分業務的服務單元保證多個業務單元獨立開發，同時分化一個核心平台組管理開發平級别需求。
思考的核心，是把平台規劃好，讓它支援TBD模式，避免出現大規模合并，除了開發測試成本，這個需要很大量管理介入協調！