我们的 SCM 是 Subversion。而且我不知道如何处理这种情况。
假设我有这些分支：
在后备箱中我们有以下特点（F）：
F1 和 F2 已准备好在 QA 环境中进行测试，因此与这些功能对应的更改将合并到 QA 分支中。 质量检查：
但是如果经理想要发布 F1，因为 QA 已经完成了 F1 要求的测试，但 F2 的情况并非如此。
这意味着我只需要将与 F1 对应的更改合并到 PRODUCTION 分支中，但这也意味着这个新结果与 QA 人员已经测试过的结果不同，这是因为 PRODUCTION 分支将只有 F1要求。我不能保证它会起作用，而且这个新的合并代码在没有经过测试的情况下投入生产感觉是错误的。
这会导致不同的问题，例如： - 如果 F1 和 F2 之间存在某种依赖关系怎么办（它们不应该自行释放） - 你永远无法确定新代码是否会工作，因为没有测试这个新合并代码的环境。
你会怎么解决这个问题？
谢谢你，对不起我的英语。
【问题讨论】：
您可以建议在 QA 分支上进行快速构建周期。回滚不需要的更改（在 QA 分支上合并回早期版本，或者为 QA 使用新分支并将仅 F1 更改合并到新的 QA 分支） - 基本上建议在代码发布到生产环境中。强调将未经测试的代码发布到 LIVE 场景中的风险。
从长远来看，设置 CI 以帮助进行持续集成和测试可能会有所回报 - 这将有助于至少在给定分支上获取代码 - 为一整套测试测试任何功能组合您选择签入分支。
祝你好运。
【讨论】：
但是如果经理想要发布 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，并发布任何准备好的功能。
【讨论】：