一、背景
1、版本控制最經常用在軟體開發領域
分支管理的政策确實很考驗對人性的了解，從理念上說它要
- 符合人性
- 能自動化的就不要人工做，缺少工具支援的流程就是耍流氓
要讓它既靈活，又簡單，就需要
- 首先别讓我記住很多規則
- 其次别讓我做很多合并
- 最後是靈活，如何讓我不要被别人耽擱
是以：
- trunk 釋出是最簡單的規則，任何時候不管是家裡，公司，新人舊人都可以記住
- 疊代分支直接開發，免去特性分支到疊代分支的合并，簡潔易行
- 提前做好疊代的規劃，疊代分支已經是比較不可分割的整體，全體特性一起上或一起延遲，靈活是有限度的
2、問題
并行軟體開發是企業級環境下軟體開發的一種不可避免的模式，這種開發模式可以說是任何大中型軟體産品和項目所必需的。然而，并行開發在為我們的開發效率提高保證的同時，也會給我們的開發管理帶來諸多問題：
- 什麼時候進行分支？
- 什麼時候進行合并？
- 如何選擇有效的分支政策？
- 如何保證不同分支上的代碼同步問題？
- 如果建立對分支通路控制的授權機制？
- 如何避免頻繁的合并沖突？
- 如何處理被複用的代碼？
二、說明
1、主幹開發
在這種模式下，開發人員幾乎總是簽入代碼到主幹，而使用分支的情況極少。主幹開發有如下三個好處：
- 確定所有的代碼被持續內建
- 確定開發人員及時獲得他人的修改
- 避免項目後期的“合并地獄”和“內建地獄”
缺點：
每次向主幹簽入并不都是可釋出狀态
主幹開發在這裡的含義如上圖，它有如下特征：
- 所有人工作在單一的主幹上
- Bug fix也在主幹進行
- 沒有代碼會被當機
- 沒有merge災難
- 不會build broken，它永遠是release-ready狀态
對于極小型的、業務功能不大變化的Service/API項目，或者是線上bug緊急fix，我們依然使用主幹開發。它是最簡單、最可控的一種。
2、按釋出建立分支
在這種模式下，在某個版本即将釋出之前，建立一個分支，該釋出版本的測試和驗證全部在該分支上進行，而最新的開發工作仍舊在主幹上進行。要遵循如下規則：
- 一直在主幹上開發新功能
- 當待釋出版本的所有功能都完成了，且希望繼續開發新功能時才建立一個分支
- 在分支上隻允許送出那些修複嚴重缺陷的代碼，并且這些修改必須立即合并回主幹
- 當執行實際的釋出時，這個分支可以選擇性的打一個标簽
3、按功能特性建立分支
這種模式是為了讓開發團隊更容易在“特性”層次上并行工作，并保持主幹的可釋出狀态。
每個使用者故事或者特性在不同的分支上開發完成，一個故事隻有通過測試人員驗證無問題後，才會被合并到主幹上，以確定主幹一直是可釋出的。
該模式的動因是希望一直保持主幹的可釋出狀态。
要想讓這種模式有效果，有一些前提條件：
- 每天都要把主幹上的所有變更合并到每個分支上
- 每個特性分支都應該是短生命周期的，理想情況下應該隻有幾天，絕不能超過一個疊代周期
- 活躍分支的數量在任意時刻都應該少于或者等于正在開發當中的使用者故事的數量。除非已經開發的使用者故事合并回主幹，否則誰都不能建立新分支
- 在合并回主幹之前，該使用者故事應該通過測試人員驗收通過。隻有驗收通過的使用者故事才能合并回主幹
- 重構必須即時合并，進而将合并沖突最小化，這個限制非常重要，但也可能非常痛苦，進而限制了這種模式的使用。
- 技術負責人的一部份職責就是保證主幹的可釋出狀态
4、按團隊建立分支
這種模式試圖解決如下狀況：在一個大型團隊裡，有很多開發人員同時工作在多個工作單元上，并且還要維持主幹總是處于可釋出狀态。
下面是按團隊分支的工作流程：
- 建立多個小團隊，每個團隊自己都有對應的分支
- 一旦某個特性或使用者故事完成了，就讓該分支穩定下來，并合并回主幹
- 每天都将主幹上的變更合并到每個分支上
- 對于每個分支，每次簽入後都要運作單元和驗收測試
- 每次一個分支合并回主幹時，在主幹上都要運作所有的測試（包括內建測試）
三、注意事項
最後，說說分支合并管理的一些注意點：
1.分支離開主幹的時間要盡可能短。長期離開主幹的分支需要定期合并。
2.輔助文檔是必需的。為了觀察分支的建立和合并的過程，至少需要一份類似泳道圖的文檔标記每一次分支建立和合并的過程。
3.開發分支往主幹或者釋出分支合并的次數應該盡可能少。一般來講應該在單體測試結束合并到主幹或者釋出分支，然後進行結合測試。如果結合測試裡發現bug不應該在原來的開發分支上繼續修改，而應該建立新的分支進行修改。
4.分支建立和合并的log必須規範。便于以後查找。基本的log資訊應該包括從哪個個分支的哪個版本建立分支；把哪個分支的從哪版本到哪個版本範圍内的變更合并到了哪個分支的哪個版本，合并後的版本号。這些資訊有一些是版本控制工具本身可以很友善查找到的，就可以省略。
四、參考路徑：
1、https://www.tapd.cn/forum/view/69961
2、https://svnbook.red-bean.com/zh/1.8/svn.branchmerge.commonpatterns.html
3、https://www.cnblogs.com/shihao/archive/2012/03/28/2421224.html
4、https://www.jianshu.com/p/87e75a69ed17
5、https://blog.csdn.net/iteye_4392/article/details/81597716