TFS分支策略針對特定變化所需的建議

Question

尋找一些分支策略來應對我們的開發工作。我們使用的是TFS 2010，它使用了一個基本的兩個分支分支場景，分別是三個分支：Dev，Main（其他兩個分支的穩定的主分支）和Release。目前Main和Release是相同的，Dev分支正在進行大量的改變。

當我們開始最新的開發項目時，假設我們會遵循我們的正常實踐，並將開發分支中的所有工作都收集到一個點，然後開始發佈過程。那麼和往常一樣，事情會發生變化，現在我們只希望在Dev分支中完成一些工作（大約20％的變化），並且希望做一個發佈。

我們希望推廣的大多數更改都是獨立的，但有幾個文件需要重新開發，並且只保留我們關心的發佈功能。

因此，鑑於我們目前的雙分支策略，我們如何協調一些本來應該更多地沿着基於多特徵的分支策略的線路進行構建的東西？

這是我們與TFS的第一個大項目，很遺憾，我們不會因變更包括東西多的功能，不使用標籤，等養成良好的資源管理

在我腦海中最糟糕的情況會以從Main創建一個新分支，將其稱爲Feature1，然後必須手動將修改從Dev分支複製到Feature1分支。這是唯一的方式，還是有更有效的東西？

Answer 1

是的，我認爲你需要創建一個新的分支。但我不會稱之爲Feature1。我會開始使用發佈分支。

從Main創建Release分支。然後，您將合併（不手動複製）您計劃包含在Dev發行版中的所有內容。如果主分支沒有更改，則合併不應導致任何衝突。現在您可以在Release分支中開始穩定工作。

工作可以在開發中繼續，當發佈準備就緒後，您將所有修復從發佈到開發以及所有更改合併到主要。

由於您今天不使用標籤，我認爲您應該鎖定發佈分支。對於下一個版本，您創建一個新版本分支。 （在開始之前，請務必考慮所有發佈分支的良好命名約定）然後，您總是能夠回到每個發行版。