我正在为我目前所处的情况寻找正确的分支和合并策略。几周前，我从 Main 为应用程序的 1.6 版创建了一个新的 Dev 分支。这个版本现在正在测试中，将在未来几周内上线。
从今天开始，我需要开始 1.7 版的开发，但我不确定如何在 TFS 中进行。我认为有两种情况：
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 合并时进行毫无根据的合并。
这是无法避免毫无根据的合并的情况，还是我的整个策略都错了？
我假设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分支上的标签来表示每个稳定版本，也可以创建发布分支来表示它们。