想象一个功能分支，我们称之为功能a，完成后合并到Develop中分支。之后，在处理分支feature C时，创建了几个特性分支，它具有在A上添加的特性，您发现特性A有一个需要修复的bug。实现这一目标的最佳方式是什么?回到分支功能A，修复bug并再次合并到开发中?修复分支功能C?固定发展?樱桃挑选吗?还是其他选择?
A---A---A B---B C---C -> found a bug on A here
/ / /
S-----------AA--------BB--- develop
回到分支Feature A，修复bug并再次合并到开发中?
绝对不是。事实上，该分支应该在合并的那一刻就被删除。
如果在当前状态下有一个bug，制作一个票据，在分支上修复这个bug，发出pull请求，然后合并，就像任何其他更改一样。这种情况没什么特别的。这个bug是从过去的分支中生长出来的这个事实是无关紧要的。
取决于问题的严重程度和优先级。
如果这个特性对于整个应用程序的功能来说是必需的，并且非常重要，需要立即修复，那么您可能应该从开发中进行分支，创建修复，然后合并回开发中。这将为您的整个项目提供修复。这可能是最像Git Flow的方法。"fix"本身是一个特性分支，就像任何其他特性分支一样。
如果功能C依赖于此功能，并且您执行了前面的操作，您现在可以将开发合并到C中并继续开发C。
如果特性C，并且只有特性C，需要这个修复，因为它暴露了一些边缘情况或其他东西，那么将修复作为自己在分支C上的原子提交是安全的。这样，它将随着特性C的引入而修复，但如果有必要，它也可以很容易地移植到以后的开发中。然而，这将延迟补丁的应用，直到它被移植(通过择优选择或其他方式)或直到特性c的部署。
最终目标在任何情况下都是完成的。最终，修复被合并到主分支中。唯一的问题是，这必须多快完成。这是您的项目需要解决的问题，并且需要了解此错误如何影响您的用户。这不是Git Flow的直接问题。