TFS分支策略不正确 - 如何修复

Question

看起来最终我们将我们的项目转移到一个糟糕的分支策略 - “级联”（问题“TFS -- Sustainability of Cascading Branches”它实际上被认为是可行的）。现在，在阅读了几篇文章并看到它导致了无限的分支树之后，我意识到它很糟糕并希望解决它。但这并不像我预期的那么容易。 TFS只允许与父分支合并（兄弟姐妹不可能合并）。

以下是我们当前的分支层次结构的图表：

看起来很奇怪，但这一切都是从最新release分支的小变化开始的，而主干在3个月的工作中被暂停。然后我们根据前一个（最多1.1.4）制作了一个中间版本。但是当我们开始发布1.2.0时，重复了trunk的故事，我们必须暂停1.2.0并实现1.1.5修补程序。

现在我需要将1.1.5更改合并到1.2.0分支中，这是不可能的。我只能将1.1.5与我想避免的1.1.4合并（谁知道我们可能需要在明天基于1.1.4实现1.1.6）。但似乎我没有别的出路。仍然可以从非最新版本的1.1.4创建1.1.6分支。

这是我必须做的，是不是有更好的出路？

现在出现了很大麻烦和主要问题。最后，我需要将所有更改合并到trunk。而1.1.5-1.2.0问题只是其中的一个缩影。这就是为什么我要求一种最佳且风险最小的方式来执行此合并。

我目前的计划如下：

1. 使用最新的稳定版本创建分支“1.1.4 final”。
2. 可选：为所有以前编号的版本创建类似的最终分支。我应该这样做吗？很可能我将来不再需要这个版本了。
3. 将1.1.5合并到1.1.4
4. 将1.1.4合并为1.2.0。 1.1.5没有太大的变化，所以我不应该在这里遇到问题。
5. 将1.1.4合并到1.1.3,1.1.2并向下release分支。 我是否应该在这里遇到冲突或问题？我希望并希望不会。
6. 将release合并到trunk。最可怕的部分=）
7. 稳定trunk。
中的代码
8. 现在是时候制定一个更好的分支策略......我现在对此部分非常不确定。
9. 从stable
创建新的“trunk”（主要）分支
10. 重新trunk成为stable的孩子。相关问题“How to fix TFS incorrect branching”
中建议使用此解决方案
11. 我应该删除当前的“release”和“R***”分支，还是将其留作垃圾？
12. 对于下一次发布版本，不要创建单独的分支 - 而是在稳定分支中标记最终版本。实际上“stable”分支只包含最终版本签到。
13. 我不打算为稳定功能的QA创建“integration”分支 - 目前我们都生活在单个活动分支中而没有问题。
14. 根据alternate创建“stable”分支进行参数开发，以防我们需要再次暂停当前工作以进行一些紧急修复。我应该永远保留单个备用分支，还是在合并后删除它并在需要时创建一个新分支（如R125）？



这种改变的想法是固定有限数量的分支（理想情况下为2，最多3-4）。

请分享您对我的策略的想法和顾虑，或提出更好的策略。我问，因为不确定这一切是否会像我预期的那样有效，不知道这是否是最简单的方法，而且错误的代价是巨大的。

Answer 1

  

这是我必须做的，是不是有更好的出路？

我 小心地执行从release下的分支到trunk的所有更改的无基本合并。我一次只做一个分支，并合并＆＃34;所有更改都达到特定版本＆＃34;并选择所有＆＃34;最新版本＆＃34;。这将为您提供一个包含发布中所有更改的主干。

  

我是否应该在这里遇到冲突或问题？

您可能会遇到冲突，但通过一些谨慎和对历史记录的一些取证调查，您可以将更改记录到trunk。

处理发布分支（即使与trunk没有直接关系的分支）时的正常过程是检查发布分支，然后检查RI（反向集成）将更改合并回trunk。有些人更喜欢先检查trunk然后合并到发布分支，以避免trunk可能被遗忘的情况。它是六个中的六个，另外六个是IMO。

  

我应该删除当前＆＃34;发布＆＃34;和＆＃34; R ***＆＃34;分支，或留下它们作为垃圾？

我认为不重要，你可以将它们移动到名为obsolete releases的文件夹中，如果你想隐藏它们，或者只是删除它们 - TFS删除是软的。

  

请分享您对我的策略的想法和顾虑，或提出更好的策略

我不会创建stable。一旦我拥有trunk中的所有内容，我会很高兴，主干/主分支的目的是成为代码的稳定可释放版本，如果开发人员不能保持这种方式（我不会责备BTW），然后在功能分支中工作，定期FI合并到功能分支是最好的方法。

接下来的位置真正取决于贵公司发布的流程。 一种选择是＆＃34;标签＆＃34; trunk当你有一个你想要的版本时。

Start -----L:R1-----C->

如果您需要在发布之前修复错误，可以从标签分支：

Start -----L:R1-----C->
           |    /
     B:R1  |--C/

检查R1分支的变化（B：R1）并将其合并回trunk。

如果需要，这会为你提供一个分支，但不是太深的结构，你最终可能会有很多分支，但你可以使用文件夹来保持它们的有序。

我希望这会有所帮助，最后请确保您阅读ALM Rangers branching guide - 它涵盖了您可能需要的主要TFVC分支策略以及何时应该使用它们。

最后，我向任何想要创建分支的人提出的问题是＆＃34;你将如何发布这些代码？＆＃34;，这有助于我创建分支来解决问题，而不是创建问题。如果我不知道如何发布代码，我就不知道构建分支的最佳方法 - 我曾经参与过一个项目，其中包含23个主要分支的层次结构，所有这些都结束了在测试或发布之前聚集在一起 - 我们可以使用一个：）。

最后，如果你有一个VSOnline帐户或其他团队项目集，你可以尝试重新创建一个更简单的问题版本并尝试解决方案。

Answer 2

你的合并stratigics看起来不错，但我会尝试完成三个分支图。

我们正在使用三个分支Dev，Test，Release。

大多数构建都来自dev并且已标记。 （与图中的主干相同）。 然后我们将其移至qa并继续开发。 如果在将来的开发中存在问题\ bug和Dev分支，我们将测试分支设置为标签并将问题修复到测试分支并将其合并到dev并再次使用标签。 如果我们遇到生产问题，我们使用发布分支上的标签修复问题，标记它并将其合并到dev。 这是如何使用三个分支完成的。

当然，你总是可以使用特征分支来实现长期和默认的特征。

Answer 3

最后，我做了合并！感谢@DaveShaw的推荐，我主要使用它们。但是想要宣传我的发明，我认为这显着节省了时间。

我没有直接从R120执行无基础合并到trunk，而是从dev和R120的公共根修订版创建了一个中间分支trunk。 }并执行从R120到dev的无基础合并。这产生了600多个冲突文件！但很容易解决它们 - 从R120获取所有内容。

然后，由于分支dev和trunk具有共同的根，我可以将它们与常规合并（非基础）合并。这比一个没有基础的文件表现得好得多，并且只生成了11个冲突文件，我可以在1天内解决它们 - 所有这些都是需要手动解决和代码编辑才能合并的真正冲突。因此，我节省了时间来区分真正的11个冲突文件和600个不是真正冲突的文件，并且可以自动解决。

接下来，我将稳定两个分支并切换其角色（当前dev似乎扮演main（稳定）并且trunk被破坏的角色。所以我决定使用分支策略“开发隔离”，它将很快演变为“开发，功能和发布隔离”。

对于我剩下的大部分问题，@ DaveShaw提供了很好的解释性答案，我没有什么可补充的。