拥有一个发布分支的风险有多大？

Question

目前，我们在项目中管理我们的源代码。我们有以下分支机构：

• 开发
  • 特征1
  • 特征2
  • 等。

• 测试

开发过程要么是在development中完成，要么是在一个单独的特性分支中完成。功能和修复完成后，它们将合并到测试分支，然后将其部署到测试环境中。当我们成功地接受测试分支时，我们从测试构建中创建一个版本，并将其部署到生产中。

采用这种方法的原因是，在构建并部署到生产之前，我们不希望从Test合并到发布分支，因为我们将部署与测试不同的代码。

这种方法的缺点是，在测试分支中经常会有未经测试的更改等待，这会延迟生产中关键bug的热修复交付。

我发现，在行业中，合并到一个发布分支，然后部署它是很常见的。是否有一种方法允许简单的热修复，并且在拥有单独的发布分支时不引入未经测试的差异的风险？

Answer 1

在像您这样的环境中，使用分支策略，生产修补程序应该发生在发布分支之外的hotfix分支上。一旦经过测试和批准，这些更改应该被合并回您的上游开发和测试分支中。这是一种高度保守的分支策略。而额外的合并是您在发布版本中获得安全级别所做的权衡之一。

Answer 2

问题的根源在于特性分支的使用(包括我在内的一些人认为它们是“邪恶的”)。将它们合并到一起以获得您的单个发布分支是您的瓶颈:分支合并是质量级别中无法避免的不连续性点，需要未知的工作量/资源，必须序列化，不能正确规划等等。它们导致未经测试/正在进行的功能待定，成为热修复和发布分支之间的障碍。

人们常常忘记，在一个分支中正常工作的变更不能保证工作正常(或者根本不工作！)在另一个分支。一个完整的特性在它自己的开发分支中可以很好地工作，但是当它与需要发布的所有其他特性合并时，它就会被完全毁了。而且你甚至无法确定是哪一个变化造成了问题:你必须采取一种全然不知的方法:要么取消合并(即不整合任何分支变更)，要么接受合并(包括所有的变化)，在质量级别上接受你需要解决的问题，永远不要考虑任何潜在的怀疑。

在持续集成方法中，没有要合并的特性分支--没有待办事项，也没有这样的障碍。任何和所有的更改都保持较小，并且可以在任何时候进入单个分支，而不管是修补程序还是新特性的一部分。故障可以立即识别和处理，自动化可以帮助很大的帮助(是的，在CI中总是有一个非常短但从不空洞的可疑列表)。没有质量水平的不连续点，质量不断被测量/监测，甚至可以通过工具自动执行。

即使您不能真正使用您的单个主/主分支作为实际的发布工具，并且确实需要发布分支(当连续部署不是一种选择时完全正常--例如，在嵌入式软件或OS开发案例中)，您仍然可以在发布分支级别使用持续集成。这意味着您永远不会重新设置/重新创建一个发布分支，也不会将其他特性/集成分支合并到其中，从而引入一组看起来运行良好的更改(在另一个分支的上下文中)。

每个更改、修补程序，甚至是“迟来的特性”开发的一部分，都是专门为发布分支开发的，或者是从其他分支提交的移植/双重开发，都要通过在接收发布分支的特定上下文中应用的相同的检查。这最终保证了该版本的最低质量水平。这就是为什么我相信CI/CD是可靠发布软件的最快方式。

Answer 3

通常，您可以采用两种版本控制方法来处理此问题：

1. GitFlow

在这里，您有长期存在的特性分支，当它们完成时，这些分支将被合并到开发分支中。当完成下一个版本的所有特性时，开发分支将合并到主分支中。当需要应用一个修补程序时，将从主分支创建一个新分支，然后在该新分支上执行该修补程序，然后将该分支合并到主分支并进行开发(然后将主分支部署到您的测试环境中，测试该版本，然后将其部署到更高的环境中)。

一个需要一段时间开发的特性分支可能存在许多合并冲突。可以通过将特性分支重新设置在开发分支上(或者通过将开发分支合并到特性分支中)来缓解这种情况。

2. TrunkBased development

在以集群为基础的发展中，没有活的分支，只有一个主分支。因此，每个提交都在主分支上，并立即部署到所有环境中。功能标志是防止在早期环境中未测试的更改在生产中可见的原因。这样，您就没有解决合并冲突的艰苦工作。但是，您需要在其位置上管理特性标志。