Answers:
一种方法是对其进行特征标记。它可以存在于代码库中，但可以通过配置禁用。
另一种选择是进行还原提交，以还原功能合并，从而使其不再处于开发状态。可以创建一个新分支来还原该还原，并留待以后合并。如果您使用的是Github提取请求，则可以通过合并的提取请求上的“还原合并”按钮轻松完成此操作。
Feature Toggling正如Doc Brown所说的那样，我们有6个月以上处于开发阶段的功能被隐藏。这也使我们能够在非生产环境中测试功能（或不存在功能）。有时，这些功能会添加到现有功能上，在这种情况下，我们应该对新旧功能集都进行单元测试。每个单元测试只会将标志设置为执行当前测试所需的任何内容。
我们如何避免这个问题？
从过程的角度来看，找出：
在此过程中，沟通下降的可能性更大。这一点很重要，因为当它不起作用时，您的开发过程将基于对业务需求的错误和错误理解。
暂时忘掉与管理人员有关的问题，想象一下您的最新产品版本中已经具有“自动注册功能”，并且已与代码库深度集成。现在，您获得了为“自动注册”添加“关闭”的新要求。您将如何在Git工作流程中处理此问题？
我猜您会简单地声明“通过配置禁用自动注册”作为一项附加功能（这只是Feature Toggle的一种形式），因此这应该可以平稳地集成到您的工作流程中。您可以估计工作量，如果您愿意，可以使用功能分支（或者如果不使用功能分支来解决此类问题，则可以不使用）。您绝对可以使用您描述的常规“合并开发->测试->主”流程。
这实际上是您在当前情况下可以解决此问题的方式。从git工作流的角度来看，变更请求是否来自1.0版的管理人员，或者变更请求是否是2.0版的新客户，都没关系。
这是我在gitflow和GitHub流上遇到的确切问题，而且似乎在Web应用程序中经常发生-或更像是正常现象。看来您可以追溯解决此问题（上述），也可以主动解决此问题（以下示例）。
除了标准的gitflow分支之外，我还创建了“捆绑分支”。该捆绑软件包含可用于uat / qa的所有功能。创建了uat / qa功能列表。这些被合并到临时捆绑包中，并且该捆绑包被部署到uat / qa。任何错误修复都发生在原始功能分支上，然后重新合并到捆绑软件中并进行了部署。这将即将发布的版本分开，并允许在找到进入开发分支的方式之前一起测试这些功能。那些批准的分支会在gitflow过程之后向开发请求请求。可以将测试就绪功能添加到临时捆绑包分支中或从中删除，然后重新部署。
缺点包括管理分发包列表和添加其他分支类型。但是，除了追溯修复（我认为为时已晚）之外，这似乎是更可行的解决方案。
使用GUI插件时，最好在每个捆绑包部署中都选中功能分支-考虑到自动化。