Git工作流：应该如何做到这一点？

对于我的大多数场景，git flow都做得很好。然而，考虑到以下情况（按时间顺序），我不确定前进的最佳方式是什么：

将1.0版推送到生产环境（使用“git flow Release”完成）

新特性的发布后开发和bug修复在开发分支中完成

在1.0版中出现了一些主要缺陷和一些缺失的需求，客户决定他们不能等待下一个主要版本，但是除了一些需要等待下一个版本的工作之外，这些缺陷/特性中的一些已经在开发分支中得到了解决

如果我们有一个水晶球，我相信我们应该将更新作为热修复而不是在开发分支中应用，但是现在已经太迟了。如果我们启动一个热修复程序（离开主分支），我们可以在分支之间复制并粘贴适当的更新（总的），但是当我们合并分支（在某个点）时，我们最终会遇到一些严重的冲突

---

在这种特殊的情况下，什么样的方法可以将头痛的问题降到最低？

创建一个热修复程序分支，然后使用“git cherry pick”从开发分支中引入特定的更改

git cherry-pick [commitid]

---

如果您将来进行常规合并，那么所选择的提交将不会重复或发生冲突，git非常聪明，可以解决这个问题。

这对我来说非常适合。我一直觉得，如果你犯了错误，就会引起冲突。谢谢你的帮助！