我正在为我目前所处的情况寻找正确的分支和合并策略。几周前，我从Main创建了一个新的Dev分支，用于应用程序的1.6版本。该版本目前正在测试中，并将在未来几周内上线。
从今天开始我需要开始1.7版的开发，但我不确定如何在TFS中继续。我认为有2个场景：
1。 1.7的dev分支是从Main创建的（像往常一样），我将所有1.6更改集成到1.7分支中并开始我的开发。一旦准备好进行测试，1.6中的任何更改都将合并到1.7分支中 2. 1.7的dev分支是通过分支1.6 dev分支创建的，1.6中的任何未来更改将再次按照第1点合并。
＃1的问题在于根据TFS在1.6和1.7之间没有直接关系，这导致无基础合并。
＃2的问题在于1.7和Main之间没有直接的关系，这导致稍后无法合并，当1.7完成并与Main合并时。
这是无法避免无根据合并的情况，还是我的整个策略错了？
答案 0 :(得分：1)
我假设Main代表您的上一个稳定版本，可能会接受修补程序等以解决关键问题。我还假设典型的工作流程是您开始开发“vNext”版本 - 在本例中为1.6，然后在该分支上工作，直到您完成它的工作，然后将其合并到{{1} }。问题是你在下一个版本中使用了不断变化的开发分支。你不想从1.6到1.7分支，因为那时你最终必须从1.7合并到1.6，然后1.6分支不再准确地反映1.6版本。
我会简化一些事情。创建两个“永久”分支：
Main - 您目前稳定的“生产”版本Main - 您的开发版本（在本例中为1.6）开发人员可以正常对抗Dev。当它“完成”并成为当前稳定版本时，它将合并到Dev。
现在，您可以创建功能分支（对于长时间运行，隔离的功能，不一定在下一个版本中发布）或“vNext”分支（对于您发现的下一个版本的内容）你有能力比预期更早开始工作。
现在，您可以为1.7工作创建Main的分支，并将1.6更改反向集成到1.7。当1.7成为新的开发目标时，将1.7合并到Dev，并删除1.7分支。
如果您想维护旧版本，可以使用Dev分支上的标签来表示每个稳定版本，或者您可以创建发布分支来表示它们。