需要基於trunk的開發建議

在做了多年的功能分支和掙扎了很多分支併合並惡夢後，我一直在尋找分支策略方面的優秀資源。功能分支確實爲我們提供了一種很好的隔離功能，以非常細化的方式管理髮行版，以便發佈哪些功能。然而，他們提出的問題（很多分支機構，合併衝突）遠比他們提供的好處多得多。需要基於trunk的開發建議

我們在後端使用Oracle數據庫（使用5000個對象）。我們也有多個團隊在同一產品的不同領域開展工作。我們使用Visual Studio和TFS（無DVCS）。

我們創建的分支越多，我們需要在這些分支（每個分支 - 一個數據庫實例）的功能測試中給出適當的隔離，這是另一組問題。

我們正在採用scrum並正在尋找適合我們的發佈週期（每年4次）和CI構建的分支模型。我們計劃爲每個版本進行5次常規衝刺和1次強化衝刺。

從分支模型的特徵，我們重新設計我們的分支模式，一個很簡單的分支像下面 -

發展分支正在爲我們的「樹幹」（中繼線基礎的發展）和所有開發人員（所有團隊）正在對該分支進行承諾（季度發佈），測試人員正在此分支進行測試，並且CI服務器（Jenkins）每天都在建設該分支。我們只是需要一個乾淨的MAIN在任何時候安全作爲「最後一次釋放真相的單一來源」，由於多種原因而經常使用。

維護分支是我們的錯誤修復分支（修補程序），並在一年中發佈多次（不論季度發佈）。我們寧願不直接在主分支上工作，因爲想要有一個「乾淨的」主分支。如果沒有進行「手動」/功能測試，我們不希望代碼進入Main。一旦錯誤修復發佈完成，代碼將從維護 - >主要 - >開發合併，以將錯誤修復集成到開發中。

我們通常不需要TBD中建議的「發佈分支」，因爲我們將持續進行維護分支中的錯誤修復，從維護版本中釋放，然後將更改合併到主要（然後開發）。我們只維護「最新版本」，如果需要以前的版本修復，我們需要從主標籤中創建一箇舊版本分支。

我們是否修改了基於主幹的開發，以至於將來會出現問題？你有什麼建議？

參見：

2016-09-18 Rajarshi

你應該從已公佈的標籤的維持性分支，只有當你遇到一個錯誤。實際上這是一個發行版分支，應該爲發行版命名。說rel_1.1。當你推出1.2版本時，很顯然你不會回滾，刪除rel_1.1。

2017-01-07 01:59:33

回答