将修订从主要合并到分支，反之亦然？

Question

在版本控制中，我们有一个主分支，最近创建了一个发行分支。我们讨论的是，在哪里解决问题以及在哪里合并（在main中修复并向前集成以发布或在release中修复并反向集成到main）。

Microsoft在其“分支和合并入门”（https://docs.microsoft.com/de-de/vsts/repos/tfvc/branching-strategies-with-tfvc?view=vsts）中指出，永远不要将main从main集成到release。但是我没有理由提出他们，我也想不到。

这有原因吗？

Answer 1

很大程度上取决于您使用SCM的特定方式-与使用哪种方式无关。
如果您是一家拥有1000名提交者的公司，那么情况会有所不同 产品，或者您正在谈论只有3个人的小型项目。

但是总的来说，将变更从主线合并到主线确实不是一个好主意 发布线。
想象一下，您的主线经常获得提交（直接提交或从其他分支合并）。
现在我们假设main分支得到了一些您在release分支中也想要的错误修正。
如果您尝试将错误修正从main合并到发行版，则可能会遇到问题，因为错误修正与您不希望在发行分支中进行的其他更改缠结在一起（可能是因为它们为下一个发行版实现了新功能）。
此外，合并过程可能会导致新的错误/错误并破坏您可能不希望的发行版。

请参阅：

这是否还取决于您是否要更改现有发行版的问题。 您可以改用之前的版本创建一个新版本，然后合并 从主要方面进行所需的更改，然后对其进行修复。

这大致相同，但是区别在于您从未接触过现有发行版（这可能对您很重要，也可能不重要）。

请参阅：

一种更新现有发行版的干净方法是分支一个临时分支 从发布分支中合并，然后合并main中的相关更改。在随后修复了临时分支之后，您可以将其合并到发行版中，该发行版现在应该是简单的复制操作，而不会破坏任何内容。

请参阅：

更新：
再次阅读您的问题后，我发现您正在考虑对发行版进行更改，然后合并到main。
恕我直言，发行分支永远不能用于开发任何更改。它应该始终仅选择在其他分支机构中开发和测试的更改。毕竟，拥有发行分支的原因在于它们是稳定且可靠的。任何发展都会破坏这一点。