正確的父/子關係，在我們的TFS服務器一個新的分支，我們有一個分支結構這樣建立在TFS
9
8.3
8.2
8.1
8.0
，其中每一分支它上面的分支的孩子，所以它很容易爲開發人員可以將他們所做的更改合併到所有後續版本（例如8.2到8.3和9中的更改）。我現在需要爲8.4添加一個分支，這裏是我的問題發生的地方。我找不到添加8.4分支的方法，該分支是9的孩子和8.3的父親。它必須以這樣的方式創建，當開發人員嘗試從它合併時，9和8.3將顯示在下拉列表中作爲可能的目標。
我以爲我可以創建一個新的分支8.0，強制合併每個分支下一級並重新命名它們，使現有的8.0將成爲新的8.1等，那麼現有的8.3將成爲8.4和一切都會好起來的。然而，事實證明，不可能完全合併一個分支（它不會刪除目標中存在的文件，但不會刪除源文件）。
有沒有辦法做到這一點？我無法使用無基礎的合併，因爲我將來無法失去進行UI合併的能力。
我不知道你是如何進入你所描述的情況的。 8.1-8.3是如何創建的？你打算如何處理9.1（或10）？
「星」的配置是比較常見的：
- 9 - 9.0
D \ / 8.3
E - QA /8.2
V/ \ - 8 - 8.1
\ 8.0
您可能不得不作出修正每一個或兩個以上的總合並，但總體來說它更加靈活。
您通過重命名提出的解決方法是一個很好的解決方法。基於現有結構，我想不出任何更好的辦法。
*問題答案*
從我這裏看到8,9不真正工作分支機構，將永遠不會被釋放，是正確的？
是的。
由於8.0不是8.1的孩子，所以如何將8.0中的更改變爲8.1。看起來，要從8.0變到8.1，你必須把它們合併成8然後回到8.1。但是，如果這是正確的，那麼你還必須將8.2變化合併爲8來使它們變爲8.3。如果是這種情況，那麼什麼可以防止意外複製到8.1的8.2更改？
你說得對，這是行不通的。我假設每個主要版本只保留一個小版本。如果以更普遍的方式繪製「星形」，則中間釋放分支（在我的示例中爲8）表示隔離。在他們的範圍內不應該有平行的變化。如果主要版本＃不足以將活動分支與活動分支分開，那麼您將需要不同的標準來應用此想法。
此外，我們目前正在8.2,8.3,8.4和9全部同時工作。我沒有看到從任何版本的8到任何版本9的任何合併路徑。是不是可以從8到9合併？另外，QA和開發分支包含什麼？看來他們只能擁有最新版本，所以在這幅圖中他們會和9一樣？
我通常會想到另一種方式。絕大多數更改都是直接在開發分支機構進行，然後逐漸推進到集成/ QA/UAT /發佈環境，並逐步實施更嚴格的質量標準。在我的圖中，這個流程是從左到右的。偶爾，您可能需要直接在右側分支中修復某些內容，例如，如果客戶在已發佈的內容中發現了高優先級問題，但這是例外情況，必須謹慎對待。在光明的一面，如果發生這種情況，那麼從右向左合併可以（&應該）樂觀地進行，即經常提前&。
如果您可以提前確定哪些更改將進入哪些版本，請相應地隔離開發分支。換句話說，如果你有工作，直到9.x才能完成工作，把它放在具有8.x特性的任何開發分支的不同分支中。這樣，後者可以安全地完成一個完整的「複製合併」（無櫻桃選擇），因爲他們的工作向右流動，確保質量保證不會浪費在沒有經過並行分支集成的代碼上（或脫離偶然的9.x依賴關係）。
直到代碼不可撤銷地發生分歧時，甚至不需要創建最右邊的分支，其中代表實際發佈。分支發佈基本上是一種信號，即開發正在關閉，而vNext正式正式啓動。從SCM的角度來看，它在更改流程中設置了一個單向的屏障，以確保舊代碼不會獲得新的依賴關係（例如，在有關將8.2更改混入8.1的問題中）。
讓我們來看看我繪製圖表時所考慮的總體順序。爲了重用上面的繪圖，我將堅持我的假設，一次只保留一個8.x和一個9.x版本。
這顯然不適合你確切的模式。爲了在併發開發中容納三個8.x版本，您需要將步驟＃5中的決定基於除版本號以外的其他內容。我對你的生意不夠了解，告訴你應該做什麼。
此外，您可能無法從9.x的功能開發8.x的功能發展，使易於分離。計劃改變。如果9.x特性提升到8.x，您可能需要從Dev分支挑選。如果在創建「8」分支之前將8.x特性踢到9.x，那麼未來將有一些艱苦的工作 - 沒有分支結構可以解決這個問題。
類似地，步驟＃5-6取決於按順序完成的事情。當8.x達到「幾乎完成」狀態（如樹的RHS代表）時，9.x分支需要開始彼此之間以及與QA分享他們的工作的同時，它會發揮最佳效果。再一次，現實通常會另有指示。對於某些解決方案來說，這很簡單：9.x團隊可以通過創建間接級別來促進&接受代碼而不影響主幹。（在圖表上，這個分支就坐落在「QA」左側，這是一些開發分支的共同父項）。
但是，如果我瞭解您的情況，功能開發可能會分成4個或更多未來發布里程碑。除非你的代碼是非常模塊化的，並且你非常喜歡cherry-pick合併，否則你可能需要一個「更加粗糙」的分支樹。想象一下，如果上面的「8」和「9」有自己獨立的Dev/QA分支陣列餵養他們。或者對於我所知道的每一個小版本，都會在其樹的一部分中需要自己的微型Dev-QA-Release促銷模型。取決於你如何最終分割彼此的主動發佈區域。無論如何，擁有多個有效的「中繼線」消除了使用QA分支的潛在調度衝突，代價是（a）將8.x更改傳播到樹的9.x部分的更多步驟（b）純粹的複雜性。我不是這種方法的粉絲，希望你能避免它。
好的，足夠今天。延伸閱讀：
簡介標準開發-QA-發行模式，我一直都沿着或多或少假設：你爲什麼想安排你的分支
介紹因此代碼通常從樹的不穩定的「邊」流向穩定的「邊」（在她的PDF幻燈片中，它是上/下而不是左/右）;爲什麼在每個方向上合併的規則有很大的不同
白皮書支持，保持（在我的圖像「QA」）的單一主線的想法是不是讓發佈分支級聯關好彼此的。
好的我已經想出了一個可行的解決方案。我會把它放在這裏，以防其他人面臨類似的情況（假設任何人都可以理解這個問題）。 我將從8.3開始分支，然後將新創建的分支重命名爲8.3，並將舊的8.3重命名爲8.4。 這會給出8.4更改可以合併到8.2和9的情況，8.3可以合併到8.4。唯一的問題是8.2不能直接合併到8.3，但我們可能不會在8.2中完成任何更多的工作，所以這應該不成問題。 如果我們確實需要在8.2中做出另一個改變，我們可以通過8.4得到這些8.3（但是我們必須小心，當我們做到這一點時不要讓8.4改變爲8.3）
如果有人仍然想評論或提出建議，這將是受歡迎的。 謝謝
哇，感謝理查德，這是工作數量驚人的你已經投入幫助我，我真的很感激。我會研究它並查看你提供的鏈接。這與我們之前使用過的任何分支結構完全不同，並且需要一段時間才能理解我的想法。再次感謝你的幫助。 – 2009-11-16 13:23:09
codeplex鏈接（tfsbranchingguideii）不再存在。這可能是更換，是一個偉大的閱讀：http://vsarbranchingguide.codeplex.com/ – Mike 2013-07-24 17:37:24