当使用 git (flow) 并拥有一个阶段/测试环境时，客户正在对开发的事物进行审查，处理未批准的功能以及已批准的功能的最佳方法是什么？
考虑几个开发人员在冲刺或连续工作流中使用不同功能的场景。功能需要由客户审查，并且为了能够在阶段环境中审查这些功能，它们必须合并到开发分支并部署。
如果，假设已经开发了两个功能，开发团队认为已经完成并推送给开发人员。客户审查它们并批准其中之一。但是现在客户想要将批准的功能发布到生产中。dev 分支现在被未批准的功能代码“污染”，无法推送到生产。
处理这种情况的最佳方法是什么？当然，实际情况要复杂得多。樱桃采摘是一个解决方案还是应该重新考虑整个流程和分支机构的处理？
这个问题（由“非批准，但已经集成”功能分支污染Dev分支）是究竟什么形容拉曼古普塔在“如何Git来完成分支的创建者”。
（GitHub库的工作流程：rocketraman/gitworkflow）
在您的情况下（gitflow），您需要在将 dev 合并到 release 之前恢复未批准功能的合并提交。
但是“gitworkflow”使用临时分支，反对 gitflow：
GitFlow 提倡有两个永恒的分支？—？
master和develop
两个工作流（gitflow 或 gitworkflow）都使用“功能”或“主题”分支：
主题分支是当前所有工作完成的地方？ - 每个问题，错误或功能一个分支，并且可以同时有许多主题分支进行开发。
一个主题最终合并到nextgitworkflow 中的分支“ ”。
但是，一个关键的区别是next分支永远不会合并到master（与永恒分支“ develop”相反，后者旨在合并到master/release在 gitflow 中）
现在
topic已经升级到next，它可以成为测试版或验收版本的一部分。因此，next 上的每个主题现在都可以进行第二轮稳定，这正是 Beta 版本/验收测试环境的目的。但是，请注意，对于 gitworkflow，我们仍然没有承诺（没有双关语！）将它
topic作为我们下一个生产版本的一部分？ -？它仍然没有合并到master.
这在概念上类似于 GitFlow 的release分支，但更加灵活和强大，因为master它不依赖next任何东西，也next从来没有被批量合并到master（不同于相应的 GitFlow 分支develop和release）。
如果 next没有合并到 master，你如何将一个功能升级到生产？
一旦判断一个主题足够稳定以发布，该主题再次毕业并合并到
master（或者可能maint），再次与--no-ff以保留主题分支的完整历史记录。
为什么这更好：
请注意，在 gitworkflow 中，不稳定和稳定的开发工作永远不会在同一分支上混合在一起。
相比之下，使用 GitFlow 我有两个选择：
- 我可以在自己的分支上单独测试我的主题，或者
- 我可以合并它来开发以进行测试。
这两种选择都没有吸引力。
- 当与其他正在进行的工作一起部署时，前者不能真正测试主题的稳定性，并且
- 后者承诺主题可能在稳定之前发展。
意义：
简而言之，在 GitFlow 中，在保持开发工作在主题分支上保持干净和隔离的愿望与通过合并主题分支与其他工作来开发以使其可见和可测试并检查冲突来集成主题分支之间总是存在无法解决的紧张关系。
Gitworkflow 允许实现这两个目标，而无需为另一个目标牺牲一个。