TFS - 層疊分支的可持續性

Question

分支引導通常描述一個不朽的「Main」分支，其特徵從Main分支出來併合並回Main，並且釋放從Main分支出來，進一步分支爲Release， ，RTM等。關於Main的指導通常簡化爲「Main中沒有垃圾」。

我正在與定期發佈（通常爲每月一次）和連續發佈的小組合作。對他們來說，似乎沒有必要將工作返回到主分支。他們使用TFS 2010 - 圖解法的分支結構看起來是這樣的：

每日基礎上由一個分支;最終該分公司進入生產。任何到分支的修補程序都直接應用到該分支，並可以選擇合併到任何未來的在飛行分支中。

這個羣體的分支策略被形容爲「級聯分支反模式」。但是這是否真的如此，因爲這些分支發佈到生產環境，然後（通常）只有很短的時間才能生存？

這種TFS級聯分支機構的做法是否可持續長期。如果不是，有什麼限制，什麼時候（在多少分支之後）可以達到？

是否有任何理由最終不會「銷燬」Main，R1，R2（等），或者是否存在一個「gotcha」，用於防止在託管源代碼庫的SQL服務器上銷燬和回收空間？

Answer 1

級聯分支可以工作。我也想不出任何技術上的原因，爲什麼摧毀非常老的（優選存檔的）分支會影響更新的級聯分支。以下是需要考慮的一些問題：

1. 開發人員必須在每次發佈後將新分支映射到其工作區。
2. 如果開發人員在發佈之前無法檢查它們，則必須手動將任何工作移動到新分支（而不是在發佈後僅檢入相同的開發或主分支）。
3. 如果您有一個或多個在Rn的子分支中工作的開發人員決定將他們的工作移動到Rn + 1，然後需要無基本的合併來避免檢入原始父Rn分支。
4. 請確保您在發佈後確實鎖定每個分支。所有這些分支機構都會增加開發商意外檢查已發佈分支的變更的風險。
5. 您需要在每個級聯之後調整構建定義和任何其他路徑特定的構件。如果所有的開發工作僅僅依靠開發（或主要），那麼主要工作空間和相關的構建/項目工件在一段時間內保持不變。
6. 當您不知道哪些功能將在Rn中出貨時，您如何獨立處理並行功能？ （如果您有一個主分支，您可以從Main獲得多個子特徵開發分支，然後僅在穩定時合併特徵分支並準備合併才能在下一個版本中發佈。）

我相信Jeff萊文森做了一個演講，描述了從單一分支開始，然後是級聯分支，然後是主+釋放以及一些變體（同時描述每個分支的優缺點）。檢出Branching and Merging Practices - Jeff Levinson (Teched 2010 Video)（或相關的Branching & Merging PPT）。

享受！-Zephan