azure-devops - Azure DevOps 和发布流程，热修复时处理版本控制？

Question

在过去的几天里，我一直在努力解决如何在使用 Azure DevOps 时处理版本控制和我们的分支策略，所以我决定找到一些关于微软如何做到这一点的更多信息。但是 .. 版本控制部分并没有真正在任何地方共享我见过.. 但我只是在这个视频中看到了他们如何处理分支： Git patterns and anti-patterns for successful developers

但是.. 我不太明白的部分是.. 将您的产品版本配置为 yaml 中的变量是很常见的。例如，在开发过程中，您可能设置了以下变量： 变量：主要：1 次要：1 补丁：0 现在假设我们发布了 1.1 版，并根据上述“发布流程”git 策略创建了发布分支。 . 我们一旦创建了发布分支，就会将我们的主分支中的版本“碰撞”到例如：变量：主要：1 次要：2 补丁：0 现在.. master 分支的所有新代码最终都会使用版本 1.2 .0.. 然而.. 如果我们突然需要修复我们的生产代码，视频中提到的发布流程分支策略将 master 分支为我们的错误修复，这将为我们提供一个版本为 1.2.(1) 的分支，

标签： azure-devopsreleaseversioningbranching-strategy

Answer 1

我在发布流程组织站点中理解它的方式，如果您剪切发布分支以与生产中的内容相对应，那么您的维护工作（即修补程序/补丁）将在release/1.1.0分支上进行。然后，您将相同的修复应用到主线（例如 master）。见下图：

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

干杯!