Question

我们正在努力实施最新Visual Studio TFS Branching and Merging Guide中ALM Rangers所描述的“基本双重分支计划”。从指导：

具有MAIN，DEV和RELEASE分支的基本分支计划支持您的下一个版本的并发开发，用于测试的稳定MAIN分支和用于任何船舶阻止错误修复的RELEASE分支。通过从MAIN创建其他开发分支来支持多个开发区域。这些是彼此的对等和MAIN的孩子。

通过为每个产品版本创建发布分支来支持其他版本。每个发布分支都是MAIN的子代，彼此之间是对等的（例如，版本2.0分支是对等版本3.0，并且都是MAIN的子代）。如果一次只支持生产中的单个版本，您可以考虑单个版本分支，并直接在此分支上修复错误。创建RELEASE分支后，MAIN和开发分支机构可以开始接受为下一个产品发布批准的更改。

我们尚未决定是否要使用单个Release分支（和标签发布），或者每个版本创建一个新的发布分支。但是，有一些问题适用于任何一种方式，这些问题似乎没有得到指导的解决。

我的主要问题是：在什么时候我们应该创建一个RELEASE分支（或者将测试过的代码移到单个RELEASE分支中，如果这是我们的方式）？

我的第一反应是只在准备好发布时才创建它，但是你遇到了为开发和测试下一个sprint的工作创建死锁的问题;在创建RELEASE分支之前，您无法将这些更改检查到MAIN（如果这样做，则更难分离您只想转到RELEASE的更改）。
第二个想法是在sprint开始时创建RELEASE分支，并且当更改通过MAIN中的测试时，将它们合并到当前的RELEASE分支。一旦我们到达sprint的末尾，我们就可以锁定RELEASE分支，并为下一个sprint创建一个新的分支。这听起来像它可以工作，但我看不到任何地方的讨论，所以我只是想看看人们在做什么。

Answer 1

我会提供与Adarsh Shah相同的建议，因为在大多数情况下，2个分支（MAIN，RELEASE）就足够了，并且使用feature branches来表示你不想立即提交到MAIN的东西因为需要一段时间才能完全准备好进行测试。通过RELEASE，我指的是每个实际版本的分支。

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

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

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推入生产环境。我发现这种方法很有效。你基本上有一个完整的sprint来解决发布分支中的最后一个问题。

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

Answer 2

以下是我的建议：

1）在Code完成之前，在Main分支上进行所有开发。代码完成是开发人员停止处理该sprint的新功能但可以修复回归错误的时间。代码完成可以在发布前几天，也可以根据您的冲刺时间长达一周。

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

3）开发人员可以在此时开始处理下一个sprint的新功能，并开始检入MAIN分支的更改。测试期间发现的任何回归问题将首先在RELEASE分支中修复，然后合并回MAIN。

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

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

没有。 1太晚了没有。 2 IMO会过早。

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

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

合并/分支战略

2 个答案: