Tfs Team Foundation Server 2012中补丁的分支

在这个问题之前，我会声明，我们可能会错误地使用TFS，这是基于对TFS如何工作以及GIT如何工作的一些早期误解

背景：

• 我们有一个主要的分支，这是我们进行所有开发的地方
• 当我们准备发布时，我们在主分支的基础上创建一个分支，并按版本命名（例如，“v8.10.0”）
• 我们从这个新分支编译并发布
• 然后我们继续开发主分支
• 如果在以前的版本中发现了一个关键问题，并且我们正在开发分支的冲刺中，那么我们需要为以前的版本创建一个补丁。在本例中，我们从发布分支创建一个新分支，并开始修复该新分支上的问题（例如“v8.10.1”）
• 然后，我们希望将我们在8.10.1分支上应用的修复程序放到主分支中，然后我们执行从8.10.1到dev的合并，这就是问题开始出现的地方。这种合并是一种毫无根据的合并，毫无疑问，合并需要数小时才能完成，需要大量手动合并，并且在合并过程结束时，通常会有少数文件在合并过程中出错。更糟糕的是，TFS通常认为它可以自动合并一些文件，而且它往往会完全错误地执行此操作，最终导致代码完全崩溃

---

我们对如何完成这项任务的基本理解似乎存在缺陷，尽管这种情况并不经常发生，但它总是会咬到我们，所以我们缺少什么，以及做我上面概述的事情的正确方法是什么？

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

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

因此，您有一个分支负责开发中的主要工作。来自main的realese分支（不是每个版本都有一个分支）。以及从发布版开始的热修复程序分支。对于版本控制，可以在发布分支（）上应用标签。现在，您可以从main到release、从release到hotfix、从hotfix到realese以及从release到main进行合并，而不会出现任何问题

实际上，测试分支和并行开发分支的工作变得有点复杂。在我的项目中，我们使用如下内容：

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

---

但如果没有这些，您的设计也应该可以工作。出现问题的主要原因是，当您可以将修补程序分支合并回发布分支，并从发布分支合并回主分支时，您正在进行无基础的合并。

为什么不将10.1合并到10.0，然后将10.0合并到主分支？这样就不会是毫无根据的…为什么每次发布时都要进行分支？您是否同时在生产中维护多个版本的应用程序？@GiorgiNakeuri-听起来这可能是一个更好的方法来实现我们一直在做的事情，我想我们并没有这样做，因为我们并不真正理解这是一种更好的方式。@GiorgiNakeuri-我们为每个版本分支，可能是因为我们对TFS应该如何工作的理解存在缺陷。我们的意图是在发布时创建代码的快照库，这样，如果我们在下一个sprint继续开发，我们迫切需要为给定的发布发布补丁，我们可以返回到该快照，对代码库进行更改并发布补丁。在大多数情况下，该补丁将分发给所有客户（这是一个SaaS应用程序，部署到不同服务器上的多个客户）。您可以创建一个名为instance relv.8.10的标签，而不是分支，并且您始终可以通过该标签获得版本。感谢Giorgi，您的深入响应帮助很大。我所做的是回滚包含无基础合并的变更集，然后从8.10.1合并到8.10.0，然后从8.10.0重新合并到main，这是一次痛苦得多的经历，事情并没有变得一团糟。使用这种方法，8.10.1分支似乎是多余的，我们可以在8.10.0分支上制作补丁，可能使用一个标签，然后将其合并到开发中。我们可能需要重新评估我们的方法，看看上面概述的东西是否对我们更有利。