Team Foundation Server 2012中的修补程序的分支

Question

我将在前面提出这个问题，并声明我们很可能错误地使用了TFS，这是基于对TFS如何工作的一些早期误解，以及GIT如何工作。

背景：

• 我们有一个主支路是我们做所有我们的发展。
• 当我们准备发布时，我们在主分支之外创建一个分支，并用版本命名（例如“v8.10.0”）。
• 我们从这个新分支进行编译和发布。
• 然后我们继续在主分支上进行开发。
• 如果在以前的版本中发现了一个关键问题，并且我们在开发分支的sprint中处于中间位置，那么我们需要为以前的版本创建一个补丁。在这种情况下，我们从发布分支中创建一个新分支，并开始修复该分支上的问题（例如“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个分支的主要工作在开发中。从主要分支（一个分支不是每个版本）。并从发布的分支修补程序。对于版本控制，您可以在发布分支上应用试用版（https://msdn.microsoft.com/en-us/library/ms181439.aspx）。现在，您可以从主要发布到发布，从发布到修补程序，从修补程序到版本，从发布到主要，都可以合并。

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

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

但没有这一切，你的设计也应该工作。您遇到问题的主要原因是您可以将热补丁分支合并回发布分支，并将发行版本合并到主分支时进行无基本合并。