Azure DevOps和发布流程，热修复时要处理版本控制吗？

Question

在过去的几天里，我一直在为如何在使用Azure DevOps时处理版本控制和我们的分支策略而苦苦挣扎，所以我决定找到更多关于微软是如何做到这一点的信息。然而..从我所看到的来看，版本控制部分并没有真正分享..但我刚刚在这个视频上看到了他们是如何处理分支的：Git patterns and anti-patterns for successful developers

然而..我不太明白的是..将您的产品版本配置为yaml中的变量是很常见的。例如，在开发过程中，您可能有以下变量setup: variables: Major:1 Minor:1 Patch:0现在假设我们发布了1.1版，并根据上面的"relase flow“git策略创建了我们的发布分支。一旦创建了release分支，我们就会将主分支中的版本"bump“到例如: variables: Major:1 Minor:2 Patch:0 Now..master分支的所有新代码都将以1.2.0版本结束。然而..如果我们突然需要热修复我们的生产代码，视频中提到的发布流分支策略将为我们的错误修复提供master分支，这将给我们提供一个1.2.(1)版本的分支。(1)，但我们实际上试图“修补”的次要和主要分支是1.1...因此，正如视频所建议的，如果我们现在将错误修复程序添加到主版本和发布分支中，我们不仅会用错误修复程序修补我们的预测代码，我们还会将其升级到一个新的次要版本。我认为这不是一种更好的代码版本控制方式，因为我们新的修复了错误的产品代码的“逻辑”版本将是1.1.1。你知道如何解决这个问题吗？

Answer 1

根据我在release flow org site中的理解，如果您将发布分支与生产中的分支相对应，则维护工作(即热修复/补丁)发生在release/1.1.0分支上。然后将相同的修复程序应用于主线(例如master)。如下图所示：

​

​

此外，如果您希望避免完整的分支合并以将修复传播到主线和其他发布分支，git cherry-pick是您的朋友。只需挑选提交到主线或其他发布分支的另一个热修复中，并进行任何必要的调整，以使其与该版本的代码一起工作。

干杯!

Answer 2

Azure DevOps和发布流程，热修复时要处理版本控制吗？

如果我们实际尝试“修补”的次要和主要版本是1.1，并且您不想使用错误修复分支来修补生产代码，那么在完成开发工作后，我们可以尝试将主分支合并到热修复中，给出版本1.2.1。

在完成上面的PR之后，我们可以将hotfix分支合并到主程序中，然后我们返回到之前的场景：

​

​

现在，我们可以忘记hotfix分支，继续在主分支上开发和发布。