Team Foundation Server 2012 中的补丁分支

Posted 2023-03-22

【中文标题】Team Foundation Server 2012 中的补丁分支

【英文标题】：Branching for a Patch in Team Foundation Server 2012

【发布时间】：2016-01-31 06:43:57

【问题描述】：

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

背景：

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

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

【问题讨论】：

为什么不将 10.1 合并到 10.0，然后将 10.0 合并到 main？这样就不会空穴来风了……

为什么每次发布时都要进行分支？您是否同时在生产中维护多个版本的应用？

@GiorgiNakeuri - 听起来这可能是我们一直在做的更好的方法，我想我们没有这样做，因为我们并不真正理解那会更好方法。

@GiorgiNakeuri - 我们为每个版本分支可能是由于我们对 TFS 应该如何工作的理解存在缺陷。我们的目的是在发布时创建代码的快照商店，这样如果我们在下一个 sprint 继续开发时，我们迫切需要为给定版本发布补丁，我们可以回到那个快照，对该代码库进行更改并发布补丁版本。在大多数情况下，补丁会分发给所有客户（这是一个 SaaS 应用程序，部署给不同服务器上的多个客户）。

您可以创建一个名为 relv.8.10 的标签而不是分支，并且您始终可以通过该标签获取版本。

【参考方案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------------->

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

【讨论】：

感谢 Giorgi，您的深入回复很有帮助。我所做的是回滚包含无基础合并的变更集，然后从 8.10.1 合并到 8.10.0，然后从 8.10.0 合并回 main，这是一次不那么痛苦的经历，事情并没有完全搞砸.使用这种方法，8.10.1 分支似乎是多余的，我们可以在 8.10.0 分支上制作补丁，也许使用标签，然后将其合并回 dev。我们可能需要重新评估我们的方法，看看您上面概述的方法是否对我们更好。