过去几个月我们一直在努力跟踪git flow，但是在QA等待时间过长的问题上一直存在问题。
以下是我们的流程：
不幸的是，客户有时可能需要数周才能批准功能。这可能是由于积压，内容创建，员工流动等等。
但是，与此同时，新功能可能已合并到dev中，并被推送到开发服务器进行审批。假设第二个功能获得批准，需要尽快部署（当然）。如何在不带第一个功能的情况下从dev中获取第二个功能？
答案 0 :(得分：2)
如果没有提供第一个功能，我将如何从
dev获取第二个功能？
你赢了。
但是，dev合并master后，master dev合并，以便记录第一个功能尚未获得批准。
这比第二个功能中的you can revert the 1st feature commits更安全，因为它会将这些提交从master复制到integration，并使将来的合并更复杂。
如果经常重复，则工作流程不适应当前的开发过程。
如果最好是：
dev分支，您可以在其中合并任何要批准的功能（在开发服务器上）。integration仅使用功能分支中的已批准功能 进行更新（在开发服务器上）。换句话说，您合并了一个功能分支两次：
dev进行正式客户审核并批准该功能dev，进行第二次（并且更快）的客户端检查，以查看该功能是否仍然按预期工作（因为它不会与集成中的代码库合并在一起）< / LI>
从prod开始，您将恢复正常的发布管理流程（推送到{{1}}）
答案 1 :(得分：1)
在我们的环境中，我们也遇到了同样的问题，客户需要花费很长时间来测试某些功能（数周！），同时还要批准应在生产中部署的其他功能。
我们处理此问题的方法是正常使用Gitflow并将功能切换添加到我们的功能中。这样，我们可以将新功能代码推送到生产环境中，但由于功能切换而无效。我们可以使用属性文件（正在使用Togglz）配置功能是否处于活动状态。
当然，代码的所有“ if”内容都有些混乱，但是好处是，如果已经在生产中但已禁用的功能得到批准，我们只需要更改文件中的属性，然后重新启动该应用程序，该应用程序将变为活动状态，无需执行新版本并将其安装在生产环境中！另外，Togglz具有功能控制台（我们尚未尝试过），显然可以在运行时进行切换。
您可以了解有关功能切换here的更多信息。 您可以了解有关Togglz here和here的更多信息。
我希望这会有所帮助：）
答案 2 :(得分：0)
这不够“git-flowy”。开发分支应仅包含签名的功能 - 因此开发中的HEAD应仅包含经过测试并准备发布到主/生产的代码。
针对您的问题的git-flow解决方案是，在完成功能的工作时，您将其上传到原点（推送功能）并将其发送给测试人员（客户端？）。
只有在获得批准后才会合并到Develop。
功能应该彼此独立，因此客户端可以按照他的时间表（*）单独测试每个功能。在您的流程中，您可能会将良好的代码和错误的代码合并在一起，并且测试结果无助于确定问题的根源。
*）如果不是这种情况，或者如果您想并行测试功能，请使用集成分支。