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