git - git hotfix 分支的目的

Question

CMIIW，上面著名的 git-flow 工作流建议进行修补程序的步骤如下:
稳定分支:'master'
工作分支:'开发'

从“master”分支“hotfix”

修复并提交“修补程序”

将 'hotfix' merge 到 'master'

将“修补程序” merge 到“开发”

删除“修补程序”

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

结帐“大师”

修复并提交到“master”并调用提交，如“调试:一些修复”

将“master” merge 到“develop”

我的猜测是“hotfix”分支试图遵循与“feature branch”相同的范式，我们不直接致力于“develop”和“master”。但是在我的情况下，'hotfix' 分支通常只需要很少的代码更改(例如，去掉导致 SQL 错误的额外逗号)，我个人认为这并不比创建新分支的工作更糟。
如果两种方式都可以，我如何判断何时使用什么？基于修复的数量？
如果我提出的方式不好，您能否具体说明它可能会导致哪些问题，或者与标准方式相比它没有提供哪些灵活性？

Answer 1

master/( or now main ) 应该随时反射(reflect)生产中正在运行的内容。
当您在修补程序分支上进行提交时，您需要测试/验证这些提交是否修复了错误。
只有完成验证步骤后，您才能 merge 到 master/main .
并且可以开发(尽管您可能会在生产中遇到一个与开发不再相关的错误，因为新功能使所述错误没有实际意义)
目标还在于避免来自 master/main 的任何 merge 。 .您 merge 到它，而不是从它 merge ，以限制任何可能的 merge 冲突。
另外， merge 是通过 --no-ff 完成的(无快进)，如 petervanderdoes/gitflow-avh issue 257 中所述: 目标是从哪个hotfix 看清楚分支 merge 创建的开发提交来自(而不是仅仅来自“主/主”)。
同样，并非所有发布到 master 的错误修复都完全适用于 develop反正。