我们的SCM是Subversion。我不知道如何处理这种情况。如果您的质量保证环境中正在测试的功能延迟发布，该怎么办？
比方说，我有这些分支：
在我们有以下的特点（F）主干：
F1和F2已经准备好要在QA环境测试，因此对应于这些功能将更改合并到QA分支。 QA：
但如果管理者希望释放F1，因为QA已经完成了F1要求testings但是这不是对F2的情况。
这意味着我只需要将对应于F1的更改合并到PRODUCTION分支中，但这也意味着此新结果将与QA人已经测试的结果不同，这是因为PRODUCTION分支只会有F1要求。我不能保证它会起作用，并且这个新的合并代码在没有经过测试的情况下投入生产是错误的。
这将导致例如不同的问题： - 如果有某种F1和F2之间的依赖关系（他们不应该对自己发布） 什么 - 你永远不会知道，如果新代码将工作，因为没有一个环境来测试这个新的合并代码。
你会如何解决这个问题？
谢谢你，对不起我的英文。
您可以推荐在QA分支上建立一个快速生成周期。回滚不需要的更改（或者合并回QA分支上的早期版本，或者为QA创建一个新分支，并仅将F1更改合并到新的QA分支中） - 基本上推荐一个快速构建和完整性测试周期，代码被发布到生产中。强调将未经测试的代码发布到LIVE场景中的风险。
从长远来看，它可能还清设置CI以帮助持续集成和测试 - 这将有助于至少获得给定分支上的代码 - 测试整个测试以用于任何功能组合你选择检查分支。
Goodluck。
但是如果管理者想要发布F1，因为QA已经完成了F1需求的测试，但F2的情况并非如此？
这就是管理者的特权。他们可以决定只发布F1。
您的责任是说F1在质量保证环境中未经过正确测试。你在你的问题中给出了原因。
这意味着我必须只将与F1相对应的更改合并到PRODUCTION分支中，但这也意味着此新结果将与QA人已经测试的结果不同，这是因为PRODUCTION分支将只有F1的要求。我不能保证它会起作用，并且这个新的合并代码在没有经过测试的情况下投入生产是错误的。
你是对的。同样，你的责任是说F1在质量保证环境中没有被单独测试过。
一般来说，使用单独的分支进行开发，质量保证和生产并不容易管理，正是由于您所描述的情况。基本上，由于您不能相信QA和PRODUCTION分支是相同的，因此您必须在合并QA分支后，在PRODUCTION分支上运行完整的测试过程。那么有独立的分支有什么好处呢？
Subversion Book有一篇关于Common Branching Patterns的文章，建议使用功能分支（QA可以直接测试），并在准备发布时合并到主干中;它建议的另一个选择是有一个树干，它被分支到释放分支，在释放之前或之后可以修复错误。
您可以通过使用feature flags来更好地控制哪些功能可以发布，您可以做的一件事 - 这允许QA并行测试F1和F2，并发布准备就绪的任何一个。