什么是"功能切换"和"功能分支"，它们之间有什么区别？
有什么优点和缺点？为什么一个比另一个好？
我在谷歌上找到了一些关于这个的文章，我倾向于"功能切换"阵营，但我不相信"功能切换"在所有情况下都是更好的选择。
功能切换是持续集成/持续交付 （CI/CD） 链（敏捷/看板项目方法）中使用的方法。基本上，您将新功能发送到处于禁用状态的生产环境，然后在管理控制台中打开该功能（如果您发现该功能已损坏，则将其关闭）。
功能分支可以是发布方法的一部分，并集成到持续集成链中。您可以在功能分支中进行开发，将分支部署到 DEV/QA，获取认证，将功能分支合并到主干，然后将主干推送到 SIT/UAT/PROD 环境。
这种方法有利有弊。功能切换需要非常严格的纪律，因为损坏/暗代码正在投入生产。这对于初创公司和商店来说非常有用，因为管理层知道如何做到这一点，并且拥有系统自动化工具（Chef/Puppet/cfengine等）。Google，Facebook，LinkedIn，WordPress都使用功能切换和系统自动化部署到生产环境中。
有一些先决条件的"技术人员"可以正确执行功能切换：持续交付/部署、持续集成、自动化单元测试、自动化集成测试、自动化压力/性能测试、系统自动化。如果没有这些，请考虑更简单的发布策略（例如功能分支）。
我在我的博客上深入讨论了这个问题：http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx
简而言之，功能分支将为您提供更好的隔离，但需要您处理延迟集成和合并的痛苦。 切换提供持续集成，但要求您以支持切换的方式设计/实现代码，并引入未完成的功能代码可能对生产产生负面影响的风险。
可以同时使用分支和切换开关（它们并不相互排斥）。 至于决定在每个场景中使用哪一个，我的想法是，除非满足以下条件，否则切换应该是默认选择：
- 很难隐藏切换背后的功能
- 对没有经过全面测试的应用程序区域有潜在影响
如果这些条件中的任何一个都成立，我可能会使用功能分支而不是切换。
功能切换需要非常严格的纪律，因为损坏/暗代码是 投入生产。
我同意 Electrawn，我已经使用功能分支 6 年了，因为在我们的例子中，我们没有先决条件。
同样重要的是要了解"Toogle策略"将功能分支策略（合并）中花费的精力转移到另一个时刻。
http://martinfowler.com/bliki/FeatureToggle.html
挂起的功能在生产中沉寂后停用切换开关非常重要。 这涉及删除配置文件上的定义以及使用它们的所有代码。 否则，你会得到一堆没有人记得如何使用的开关。在我听说过的一个令人难忘的例子中， 它需要对 Linux 内核进行特殊的重新编译，以处理足够的命令行开关。
注意：遵循SCM原则，如果有人打开和编辑文件，则可能是损坏的代码。
所以，在我看来，我不相信"在所有情况下都有更好的选择"，因为这取决于你团队的文化以及你是否有测试封面。
嗯，这是一个非常有争议的问题。
就我而言，我仍然更喜欢功能分支策略。保持 SCM 最佳实践并规划路线图，合并过程往往是一种简单的方法。在这一年里，我听到很多人抱怨合并过程，但根据我的经验，很多情况下合并的问题是一样的，"沟通失败":)
很抱歉答案不准确，但我认为在 SCM 中围绕这个主题有一些人类方面是更好的选择。