正确的父/子关系，在我们的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