Team Foundation Server 2012 中的补丁分支

Question

我将在这个问题的开头声明我们可能错误地使用了 TFS，这是基于早期对 TFS 工作方式与 GIT 工作方式的一些误解。

背景：

• 我们有一个主分支，这是我们进行所有开发的地方。
• 当我们准备好发布时，我们会从主分支创建一个分支并按版本命名（例如，“v8.10.0”）。
• 我们从这个新分支编译和发布。
• 然后我们继续在主分支上进行开发。
• 如果在之前的版本中发现了一个关键问题，并且我们在开发分支的冲刺中处于中流状态，那么我们需要为之前的版本创建一个补丁。在这种情况下，我们从发布分支创建一个新分支并开始修复该新分支上的问题（例如“v8.10.1”）。
• 然后我们希望将我们在 8.10.1 分支上应用的修复程序放到主分支中，因此我们执行从 8.10.1 到 dev 的合并，这就是问题开始发生的地方。这种合并是毫无根据的合并，毫无疑问，合并需要数小时才能完成，涉及大量手动合并，并且在该过程结束时，通常有少数文件在合并过程中被搞砸了。更糟糕的是，TFS 通常认为它可以自动合并一些文件，但这样做往往会完全错误，我们最终会得到完全破坏的代码。

我们对如何完成这项任务的基本理解似乎存在缺陷，虽然它不经常发生，但它总是困扰着我们，所以我们缺少什么，以及做我所拥有的正确方法是什么上面列出的？

Answer 1

嗯，有很多分支策略，只有你才能决定哪一个最适合你。我从问题中看到的是你有主要的开发分支和发布分支。您没有用于测试的分支。您没有并行开发的分支。您有修补程序的分支。组织分支的一种方法是：

O----------------main dev branch------------------>
    |                                             ^
    V                                             |
    O---------------release branch---------------->
         |                                        ^
         V                                        |
         O--------------hotfix branch------------->

因此，您有 1 个分支用于开发中的主要工作。从 main 分支为 realese（一个分支不是每个版本）。并从发布分支获取修补程序。对于版本控制，您可以在发布分支上应用标签 (https://msdn.microsoft.com/en-us/library/ms181439.aspx)。现在，您可以毫无问题地从主版本合并到发布版本、从发布版本到修补程序、从修补程序返回到 realese 以及从发布版本到主版本。

实际上，测试分支和并行开发分支会变得有些复杂。在我的项目中，我们使用这样的东西：

O--------parallel dev2---------------------------->
^                                                 |
|                                                 V
|    O---parallel dev1---------------------------->
|    ^                                            |
|    |                                            V
O------------------main dev branch---------------->
     |                                            ^
     V                                            |
     O--------------test branch------------------->
         |                                        ^
         V                                        |
         O--------------relese branch------------->

但没有这一切，你的设计也应该有效。您遇到问题的主要原因是当您可以将修补程序分支合并回发布分支并从发布回到主分支时，您正在执行毫无根据的合并。