是否有一种解决方案可以使用Git flow处理非线性发布计划？

到目前为止，Git流模型在我们公司运行良好，但我们想知道一个解决方案来处理这种假设情况。我四处搜索了一下，但我认为我对这个案例缺乏合适的术语可能会妨碍我的谷歌搜索引擎

如果您的所有发布都必须“来自”合并提交到

主

分支，如下所述：

那么，您如何处理这样一种情况：先发布

0.2.0

，然后发布

0.3.0

，然后发布

0.2.1

？此时，必须从0.2.x开发分支执行发布（假设存在一个分支，或者从

0.2.0

标记创建）？当然，您不能合并回master，因为您的补丁版本可能有好几次提交

是最好的解决方案，比如：

git checkout tag-release-0.2.0
git checkout -b some-0.2.1-critical-feature
.. (work) ..
git commit
# At this point, the release-0.2.x-branch is the same as the above release tag
git checkout release-0.2.x-branch
# Merge the feature branch into the patch release branch
git merge some-0.2.1-critical-feature
# NOTE here! Release occurs from the patch branch!
git tag tag-release-0.2.1
# Merge patch fixes into develop
git checkout develop
git merge tag-release-0.2.1

---

还有比这更好的解决方案吗？如果规则要合并到master中执行发布，那么在下一个小调/大调之前不需要发布任何补丁吗？

类似于我的问题，仍然没有得到真正令人满意的答案。

git flow support

命令我认为可以处理这种情况。。。但我不确定它是否被正确地完成了。。。