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

Question

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

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

现在已经完成了合并：假设我们现在突然面临生产不稳定（多么不幸！），master和develop分支现在暂时与生产环境不同步，发布（比如说1.1）被推迟了。 。 后来，我们发现了需要一个或多个修复程序的问题：在您看来，如果知道master和development现在与prod不同步，处理一个或多个错误修复的最佳方法是什么？

• 我应该从development创建一个新的发行分支（并以1.2命名），然后将变更从master转变为最新的生产发行标签（比如1.0）吗？ 如果是这样，什么是最好的方法，以便可以尽可能保留更改的历史记录？
• 对于那些具有发行周期实际经验的人：您是在发行后合并发行分支还是在发行前乐于合并？

编辑：总而言之，这个问题实际上是关于澄清在发布周期之后以及在将该版本部署到环境之前处理错误修复时所需的工作量。 目的是阐明在部署到生产环境（基本上是从发行分支而非母版发行到环境）之后，通过执行发行周期合并（合并到母版/开发中）可以节省多少动作。

Answer 1

您链接的文章中指出

主分支存储官方发布历史记录[...]

因此， 根据定义 ， release分支合并到master就是发行。 您描述的工作流中不是这种情况，因为您还有另一个production实例，该实例可以在不久的将来从master获取更新。

话虽如此，我认为您所处的最佳方法是从production创建一个hotfix分支，解决您的问题并将其合并到production以及develop和master 。 然后可以按计划进行从母版的“发布”，同时尽快解决您的production问题。

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