合并/分支策略答案

【问题标题】：Merge/Branch Strategy合并/分支策略
【发布时间】：2013-12-31 16:02:47
【问题描述】：

我们正在尝试实施 ALM Rangers 在最新的Visual Studio TFS Branching and Merging Guide 中描述的“基本双分支计划”。来自指南：

包含 MAIN、DEV 和 RELEASE 分支的基本分支计划支持您的下一个版本的并发开发，一个用于测试的稳定 MAIN 分支和一个用于任何船舶阻塞错误修复的 RELEASE 分支。通过从 MAIN 创建额外的开发分支来支持多个开发领域。这些是彼此的对等对象，也是 MAIN 的子对象。

通过为每个产品版本创建版本分支来支持其他版本。每个发布分支都是 MAIN 的子节点，并且彼此是对等的（例如，发布 2.0 分支是发布 3.0 的对等分支，并且都是 MAIN 的子节点）。如果在生产中一次只支持一个发布，您可以考虑一个发布分支，并直接在这个分支上进行错误修复。一旦创建了 RELEASE 分支，开发分支就可以开始为下一个产品版本进行更改。

我们不确定是要使用单个发布分支（和标签发布），还是要为每个发布创建一个新的发布分支。但是，有一些问题适用于任何一种方式，但指南似乎没有解决这些问题。

我的主要问题是：我们应该在什么时间点创建一个 RELEASE 分支（或者如果我们这样做的话，将测试代码移动到单个 RELEASE 分支）？

我的第一反应是仅在准备好发布时才创建它，但是您会遇到为下一个 sprint 工作的开发和测试创建死锁的问题；在创建 RELEASE 分支之前，您无法将这些更改签入 MAIN（如果这样做，将更难分离出您只想转到 RELEASE 的更改）。
第二个想法是在 sprint 开始时创建 RELEASE 分支，当更改通过 MAIN 中的测试时，将它们合并到当前的 RELEASE 分支。一旦我们到达 sprint 的结尾，我们可以锁定该 RELEASE 分支，并为下一个 sprint 创建一个新分支。这听起来可行，但我在任何地方都没有看到关于它的讨论，所以我只是想看看人们在做什么。

【问题讨论】：

标签： tfs merge branch branching-and-merging

【解决方案1】：

我会给出与 Adarsh Shah 相同的建议，因为在大多数情况下 2 个分支（MAIN、RELEASE）就足够了，并且对于您不想立即提交到 MAIN 的事情使用 feature branches，因为这需要一段时间才能完全准备好进行测试。 RELEASE 我的意思是每个实际版本都有一个分支。

请记住，理论上，MAIN 应该随时处于发布就绪状态。这意味着也使用功能分支进行很多小的更改，并且只要功能尚未准备好，就不会将内容合并到 MAIN 中。现在，这是您应该尝试的东西，看看什么在您的环境中最有效。如果您发现将 MAIN 保持在发布就绪状态太难，请务必创建一个单独的 DEV 分支来提交日常工作。然而，根据我的经验，通过一些好的指导方针、自动化和手动测试，您可以快速进入一个可以认为 MAIN 相当稳定的流程。我曾在我们有一个非常不稳定的 DEV 分支和一个稳定的 MAIN 分支的环境中工作，以及我们没有 DEV 分支的环境。有时需要 DEV 分支，有时使它们保持同步成为一种负担，因为 DEV 和 MAIN 都相当稳定，基本上只是彼此的副本。

现在，您应该何时创建发布分支。这取决于您正在进行的开发类型。对于具有相当稳定发布周期的小型桌面项目或网站（例如，每个 sprint 一个版本），我发现在 sprint 的 end 创建一个发布分支并仅推送它是最容易的之后生产 sprint。

S1 - - S2 - - S3 - - S4 // Each sprint
     \ R1 - \ R2 - \ R3 // Release branch created at the end of a sprint
            \ P1 - \ P2 // Pushed to production at the start of the next sprint

因此，在 S1 结束时，我从 MAIN 创建了发布分支 R1，但它尚未推送到生产环境。在 S2 期间，两个新功能都在 MAIN 上实现，严重错误在 R1 上得到修复。如果对 R1 的修复获得批准，如果需要，它也会合并回 MAIN。在 S2 结束时，会创建一个新的 R2，并将 R1 推入生产。我发现这种方法效果很好。你基本上有一个完整的冲刺来解决发布分支中的最后一个问题。

当然，如果生产中出现严重的严重错误，则此错误将优先于其他所有内容。然后可以从生产中的现有 R 分支创建一个 RXa、RXb、... 分支，实施热修复并将该热修复推送到生产中。然后，您可以考虑是否需要将热修复中的更改合并到您的 MAIN 分支中。不要在 MAIN 分支上创建热修复并将其合并，您会发现它很快变得过于复杂，因为在 MAIN 上可能已经更改了很多周围的代码。

【讨论】：

【解决方案2】：

以下是我的建议：

1) 在主分支上进行所有开发，直到代码完成。代码完成是开发人员停止为该 sprint 开发新功能但可以修复回归错误的时间。代码完成可以在发布前几天完成，也可以在一周内完成，具体取决于您的 sprint 多长时间。

2) 在此时从 MAIN 创建一个新的 RELEASE 分支。将分支部署到 QA/Staging 环境以进行冒烟测试。之后，QA 团队将使用 RELEASE 分支进行发布测试。

3) 开发人员可以在那时开始为下一个 sprint 开发新功能，并开始签入对 MAIN 分支的更改。在测试过程中发现的任何回归问题都将首先在 RELEASE 分支中修复，然后再合并回 MAIN。

4) 对 RELEASE 分支中代码的任何更改都将被推送到 QA/Staging 以进行进一步测试。

5) 发布完成后，生产中发现的任何错误都将在 RELEASE 分支中修复并热修复到 Prod 并合并回 MAIN。

没有。 1 为时已晚，没有。 IMO 2 太早了。

我建议为每个 RELEASE 创建一个新分支，然后定期删除旧的 RELEASE 分支，而不是使用标签。

此外，我更喜欢只有 2 个分支 MAIN（也是 DEV）和 RELEASE，除非任何分支开发人员需要任何特定的功能/框架更改等。在根文件夹下，我通常创建 MAIN、RELEASES（所有发布分支）和分支（特定于功能/框架更改等的所有分支，但这些仅在特殊情况下创建，并非总是如此）

【讨论】：