合并/分支战略

Question

我们正在努力实施“基本双支部计划”，正如ALM游侠在最新的分支和合并指南中所描述的那样。根据指导意见：

带有MAIN、DEV和release分支的基本分支计划为您的下一个版本提供了并发开发、用于测试的稳定的主分支和用于任何ship阻塞错误修复的发布分支。通过从MAIN创建额外的开发分支来支持多个开发区域。这些人是彼此的同龄人和主要的子女。 通过为每个产品发行版创建发布分支来支持其他版本。每个发布分支都是MAIN的子分支，也是彼此的对等点(例如，Release2.0分支是对等版本3.0，两者都是MAIN的子级)。如果一次只支持一个版本，您可以考虑一个发布分支，并在这个分支上直接修复bug。一旦创建了发布分支，开发分支就可以开始接受为下一个产品发行版批准的更改。

我们还没有决定是否要使用单个发布分支(和标签发布)，还是每个版本创建一个新的发布分支。然而，有一些问题适用于任何一种方式，似乎没有解决的指南。

我的主要问题是:我们应该在什么时候创建一个发布分支(或者将测试代码移动到单个发布分支，如果我们就是这样做的话)？

1. 我的第一个反应是只在准备好执行发行版时才创建它，但接下来您会遇到为开发和测试下一个sprint的工作创建一个死锁的问题；在创建发布分支之前，您不能将这些更改签入MAIN (如果创建了，那么只想要发布的更改就更难分离了)。
2. 第二个想法是在sprint开始时创建发布分支，当更改通过主测试时，将它们合并到当前的发布分支。一旦我们到达sprint的末尾，我们就可以锁定发布分支，并为下一个sprint创建一个新的分支。这听起来很管用，但我没有看到任何地方都在讨论它，所以我只想看看人们在做什么。

Answer 1

我会给出与阿达什沙阿相同的建议，因为在大多数情况下，两个分支( MAIN，ready )就足够了，并且对于那些您不想立即提交到MAIN中的东西，使用特征分支是足够的，因为需要一段时间才能完全准备好测试。我所说的发布指的是每一个实际发布的分支。

不过，请记住，在理论上，MAIN应该在任何时候都处于可发布的状态.这意味着在许多小的更改中也使用特性分支，并且只要特性还没有准备就绪，就不会将事物合并到MAIN中。现在，这是您应该试验的东西，看看什么在您的环境中最有效。如果您发现MAIN很难保持到发布就绪状态，那么无论如何，创建一个单独的DEV分支来提交日常工作是非常困难的。然而，在我的经验中，有了一些好的指导原则、自动化和手动测试，您可以很快地进入一个流程，其中MAIN可以被认为是相当稳定的。我工作过的环境中，我们有一个非常不稳定和稳定的主要分支的DEV分支，以及我们没有DEV分支的环境。有时需要DEV分支，有时使它们保持同步成为负担，因为DEV和MAIN都相当稳定，基本上只是彼此的副本。

现在，您应该什么时候创建发布分支。这取决于您正在做的开发类型。对于具有相当稳定的发布周期的小型桌面项目或网站(例如，每个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期间，两个新特性都是在R1上实现的，而关键的bug是固定在R1上的。如果批准了对R1的修复，如果需要的话，它也会被合并回MAIN。在S2的末尾，创建了一个新的R2，并将R1推入生产中。我发现这种方法效果很好。基本上，您有一个完整的sprint来解决发布分支中的最后问题。

当然，如果在生产过程中出现了严重的严重错误，那么这个bug将获得比其他更高的优先级。RXa，RXb，..。然后可以创建生产中的现有R分支，实现热修复并将该热修复推到生产中。然后，您可以考虑是否需要将热修复中的更改合并到主分支中。不要在主分支上创建一个热修复程序并将其合并，但是您会发现它很快就变得太复杂了，因为在MAIN上，很多周围的代码可能已经改变了。

Answer 2

以下是我的建议：

1)在代码完成之前，在主分支上进行所有开发。代码完成是开发人员停止为sprint开发新特性的时候，但是可以修复回归错误。代码完成可以是在发布前几天，或者根据您的sprint时间最多为一周)。

2)在这一点上从主服务器创建一个新的发布分支。将分支部署到QA/暂存环境以进行冒烟测试。在此之后，QA团队将使用发布分支为发布进行测试。

3)开发人员可以在这一点上开始为下一个sprint开发新特性，并开始签入对主分支的更改。在测试过程中发现的任何回归问题都将首先在发布分支中修复，然后合并回MAIN。

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

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

1号太迟了，2号太早了。

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

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