一旦发布版本准备发布并合并到开发和发布中，如何处理GitFlow（或其他进程）中的错误修复主

Question

来自https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow：

  

一旦发布准备好发布，它就会被合并到master中   并开发，然后发布分支将被删除

现在已完成合并：假设我们现在突然面临生产不稳定（多么不吉利！），主设备和开发分支现在暂时与生产环境和发布不同步（比方说1.1） ）被推迟。后来我们发现需要一个或多个修复的问题：您认为处理一个或多个错误修正的最佳方式是什么，因为知道master和develop现在与prod不同步？

• 我应该从开发创建一个新的发布分支（并将其命名为1.2），然后将更改从master恢复并开发到最新的生产发布标记（比方说1.0）？如果是这样的话：什么是最好的方式，以便尽可能地保留变化的历史？
• 对于那些具有实际发布周期经验的人：您是否想要在发布后合并您的发布分支，或者在发布之前这样做是否满意？

编辑：总之，这些问题实际上是关于澄清在发布周期之后和发布部署到环境之前处理错误修复所需的工作量。目标是澄清在部署到生产环境之后通过执行发布周期合并（进入master / develop）可以节省多少个动作（基本上从发布分支而不是master发布到环境）。

Answer 1

在您链接的文章中，声明

  

主分支存储正式发布历史记录[...]

因此，release分支到master的合并是，按照定义，一个版本。在您描述的工作流程中情况并非如此，因为您有另一个production实例，可在不久的将来从master获取更新。

话虽如此，我认为在您的情况下最好的方法是从hotfix创建production分支，修复您的问题并将其合并到production以及{ {1}}和develop。然后，主人的“释放”可以按计划进行，同时尽快修复master个问题。

该appoach非常接近GitFlow修补程序工作流程，如您链接的文章中所述。由于您唯一要做的就是错误修正，因此与完整版本相比，修补程序工作流程更为合适。