问题描述
软件部署生命周期如下（使用git-flow）：
1. 在本地或开发环境上进行测试。
2. 提交拉取请求将功能合并到develop分支。
3. 我们的测试人员对功能进行测试。
4. 如果被拒绝，我们创建一个新的bug修复，我们在本地测试并提交一个新的拉取请求，将其与develop分支合并。
5. 在迭代结束时，我们从develop分支创建一个发布版本。
6. 将发布版本部署到验收环境。
7. 当所有相关方接受后，我们完成发布，将发布分支合并到主分支。
8. 然后将主分支部署到生产环境。
这个流程过去一直很好用，但现在我们被迫在每个迭代结束时创建一个新的发布版本，这意味着develop分支可能包含在发布时等待修复的被拒绝的功能。
更复杂的是，我们有两个仓库，一个用于前端，一个用于后端，它们必须保持同步。也就是说，我们的前端不能包含依赖于被测试人员拒绝并且在发布之前不会完成的API端点的功能。
我很困惑，真的需要一些建议。
[对于这个长评论，我很抱歉，但我认为这个问题需要一些背景信息。]
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
你可以使用与Trunk Based Development（TBD）中使用的相同工具来处理主干中的工作进展（主干是唯一一个非发布TBD分支，具有更长的生命周期）：
– 特性切换（feature-toggles）/特性标志（feature-flags）
– 分支抽象（branch by abstraction）
这些方法允许在任何时候将功能合并到develop/master中，而不需要实际启用功能（完成/可用）。
如果这些方法在技术上是使用可配置的方式实现的，那么在任何时候都可以通过在相应的测试环境中切换配置标志来测试启用和禁用功能。否则，可能需要特殊的构建来启用它们（仍然比使用功能的完整/部分代码进行分支合并要容易得多）。
然后，你可以在develop/master中运行所有的功能测试，逐个启用你的功能。
但是，如果你走这个方向，为什么还要纠结于git_flow并遇到所有这些问题呢？直接采用TBD和CI/CD吧 :)
方案2
使用特性切换或分支抽象等方法可以在主干中处理未经测试的功能，但需要一些额外的配置和管理。
另一种方法是使用特性切换或分支抽象等方法来处理未经测试的功能。这些方法可以让你在主干中合并功能，而不需要实际启用它们。这样，你就可以在开发/主干中运行所有的功能测试，逐个启用你的功能。
然而，这种方法可能需要一些额外的配置和管理，以确保功能切换的正确性和一致性。你需要确保在发布时禁用未经测试的功能，并在测试完成后启用它们。此外，你还需要定期清理不再需要的功能切换或分支抽象代码，以避免产生死代码路径和维护负担。
请注意，这两种方法都有其优缺点，你需要根据你的团队和项目的具体情况选择适合你的方法。
评论1：这是我见过大型团队的工作方式。唯一有点烦人的是，对于小的更改，特性切换很容易清理，但对于较大的特性切换，往往会留下“手术疤痕”和死代码路径（特性切换保留“以防万一”）。所以你需要一些纪律（例如，每个特性标志都有一个到期日期），以某种方式强制你清理旧代码。2. @simbo1905 是的，我也看到过这种情况。确实是纪律的问题，但我经常看到清理工作失去了进展/从优先级列表中消失 – 在较大的团队中通常不在开发人员的控制范围内。尽管如此，综合考虑，一些死代码与分支混乱和集成问题相比，无足轻重。