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

Question

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

微软在他们的“Branching and Merging Primer”（https://docs.microsoft.com/de-de/vsts/repos/tfvc/branching-strategies-with-tfvc?view=vsts）中指出，永远不应该从主要释放。但他们没有给出我的理由，我也想不出一个。

是否有一个原因？

标签： version-controlbranching-and-mergingrelease-management

Answer 1

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

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

看：

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

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

看：

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

看：

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