合并/分支策略

Question

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

基本分支计划包括MAIN、DEV和RELEASE分支，为您的下一版本提供并发开发，为测试提供稳定的MAIN分支，并为任何阻止发布的错误修复提供RELEASE分支。通过从MAIN创建其他开发分支来支持多个开发区域。这些分支是彼此的同级和MAIN的子级。

通过为每个产品发布创建发布分支来支持其他发布。每个发布分支都是MAIN的子级，彼此同级（例如，2.0版本的发布分支与3.0版本的发布分支均为MAIN的子级）。如果仅在生产中支持单个发布，则可以考虑使用单个发布分支，并直接在此分支上进行错误修复。创建RELEASE分支后，MAIN和开发分支可以开始获取批准用于下一产品发布的更改。

我们还没有决定是否要使用单个发布分支（并标记发布），还是为每个发布创建一个新的发布分支。然而，有一些问题适用于任何一种方式，似乎指南中没有涉及。

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

1. 我的第一反应是只有在准备发布时才创建它，但是这会为下一个迭代的开发和测试创建死锁；在RELEASE分支创建之前，您无法将这些更改检入到MAIN中（如果这样做，就更难分离出您只想要进入RELEASE的更改）。

2. 第二个想法是在迭代开始时创建RELEASE分支，并且随着更改在MAIN中通过测试，将它们合并到当前RELEASE分支。一旦到达迭代结束，我们可以锁定该RELEASE分支，并为下一个迭代创建一个新的分支。这听起来很可行，但我没有看到任何讨论，所以我想看看人们正在做什么。

- RebelScum

Answer 1

我会给出与Adarsh Shah相同的建议，在大多数情况下只使用2个分支(主分支和发布分支)，并使用特性分支来处理那些不准备立即提交到主分支中的内容，因为需要花费一定时间进行完全测试。而发布分支是指每一个实际版本都对应一个分支。

但请注意，理论上，在任何时候，主分支都应该处于可以发布的状态。这意味着对于许多小变化也要使用特性分支，并在将特性分支合并到主分支之前确认特性已经准备好了。不过，您应该尝试并找出在您的环境中最适合的方式。如果你发现维护主分支处于可发布状态很困难，那么可以创建一个单独的DEV分支来提交日常工作。但是从我的经验来看，在一些好的指导方针、自动化和手动测试的帮助下，您很快就可以进入一个流程，使主分支非常稳定。我曾经在一些环境中工作过，有一个高度不稳定的DEV分支和一个稳定的主分支，也有一些环境没有DEV分支。有时候需要DEV分支，有时候则会变成维护两个 DEV 和主分支的负担，因为它们都非常稳定并且本质上只是相互复制。

现在，何时创建发布分支取决于您正在进行的开发类型。对于小型桌面项目或具有相当稳定发布周期的网站(例如每个sprint只发布一次)我认为最容易在sprint结束时创建一个发布分支，并在下一次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-branch的RXa、RXb等分支，实现热修复并将其推送到生产环境中。然后可以考虑是否需要将热修复的更改合并到你的MAIN分支中。不要在MAIN分支上创建热修复并将其合并，因为在MAIN上，许多周围的代码可能已经发生了变化。

- Jensen

Answer 2

这是我建议的做法：

1）在代码完成之前，所有开发都在主分支上进行。代码完成是指开发人员停止为该迭代添加新功能但可以修复回归错误的时间。代码完成可能在发布前几天或根据您的迭代长度长达一周。

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

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

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

5）完成发布后，在生产中发现的任何错误都将在RELEASE分支中进行修复，并进行热修复以及合并回主分支。

在我看来，第1点太晚了，第2点太早了。

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

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

- Adarsh Shah