git热修复分支的用途

Question

​

​

上面著名的git-flow工作流提示进行修补的步骤如下:稳定分支：“主”工作分支：“开发”。

1. 分支从“主程序”
2. 修复中退出，并将“
3. 合并”修补程序提交到“主”
4. merge‘hotfix“到”develop“

H 110del 'hotfix’H 211G 212

我的问题是，为什么我们需要创建一个“修补程序”分支？如果我们这样做会有什么害处/缺点/缺乏灵活性？

1. 签出‘主’
2. 修复并提交到‘主’，并调用提交像“调试:一些修复”
3. 合并‘主’到‘开发’

。

我猜想，“hotfix”分支正试图遵循与“特性分支”相同的模式，在这种情况下，我们并不直接致力于“开发”和“主人”。但是，在我的情况下，“热修复”分支通常只需要很少的代码更改(例如。去掉导致SQL错误的额外逗号)，我个人并不觉得创建一个新分支的工作更糟糕。

如果这两种方式都很好，我如何判断什么时候使用什么？根据修复的数量？

如果我提议的方法不好，你能说明它可能导致哪些问题，或者它与标准方法相比没有提供哪些灵活性吗？

Answer 1

master/ (or now main)应该反映生产中在任何时候运行的内容。

当您在hotfix分支上执行提交时，您需要测试/验证这些提交是否修复了错误。

只有完成验证步骤之后，才能将其合并到master/main中。

以及开发的可能性(尽管您可以在生产中有一个与开发无关的bug，因为新特性使所述的bug模拟)

目标还在于避免从master/main进行任何合并。您合并到它，而不是从它，以保持任何可能的合并冲突限制。

另外，合并是用--no-ff完成的(没有快速转发)，正如petervanderdoes/gitflow-avh issue 257中所讨论的:目标是清楚地看到由合并创建的开发提交来自哪个hotfix分支(而不是仅仅来自“主/主”)。

同样，并不是所有的错误发布都完全应用于develop。