主要分支有dev、master。在 dev 分支中，当前版本的工作正在进行中。在 sprint 的中间，来自上面的请求实现该功能，该功能将（应该）在当前版本之前发布。接下来应该是什么？来自 master 的新分支，其中将实现新功能，之后 master merjim 将在 dev 中？在哪里可以尊重此类案例的正确方法？
只是现在项目上发生的事情是垃圾。与 dev 的合作已经停止，我们将 dev 回滚到 master 的状态，我们在 dev 中开发功能（本质上具有 master 的状态），我们滚动之前的 maid 状态。
我认为在这种情况下不太可能有“规范”的正确答案。这样做的原因是，如果您在敏捷 sprint 中工作，那么在 sprint 中间添加一个大特性并不是一个适当的做法。所以，其实你描述的 git-flow 和这种开发风格是不兼容的（当任务意外到达时）。
我会假设你仍然需要你目前在 dev 中拥有的功能，所以扔掉它不是一个选择。在这方面，我建议以下解决方案：
如果您陷入任务块或像这样的巨大功能中是正常的做法，那么我建议您稍微重新考虑 git-flow 以采用以下方法：
这种 git-flow 将更加灵活，并允许您“从上方”推送此类突发任务，而不会在存储库中造成灾难性后果。主题分支总是有机会从 dev 更新（如果那里合并了一些其他功能） - 更新。
在实践中还没有看到充分使用 git-flow。
或者dev中的垃圾，分支立即合并到master中，然后为了美观而合并到dev中。
或者所有的工作都在dev中完成，为了美观而合并到master中。在第二种情况下，dev 和 master 在内容上匹配。
我建议考虑在任何情况下从 dev 分支中放弃 git-flow 的选项。从 master 创建工作和发布分支更加容易和清晰。
这个问题的答案是一个修补程序。