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

Question

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

Microsoft 在他们的“Branching and Merging Primer”(https://docs.microsoft.com/de-de/vsts/repos/tfvc/branching-strategies-with-tfvc?view=vsts) 中指出，永远不应该从 main 向前集成到 release。但他们没有给出我的理由，我也想不出一个。

这是有原因的吗？

Answer 1

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

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

见：

这也取决于您是否要更改现有版本的问题。 您可以改为基于前一个版本创建一个新版本，然后合并 从 main 中进行所需的更改，然后修复它们。

这或多或少是相同的，但不同之处在于您从不接触现有版本（这可能对您很重要，也可能不重要）。

见：

更新现有版本的一种干净方法是分支出一个临时分支 从您的发布分支中，然后合并来自 main 的相关更改。随后修复临时分支后，您可以将其合并到版本中，这现在应该是一个简单的复制操作，没有破坏任何东西的风险。

见：

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