我们的团队现在正在发布火车部署模型（http://thinking-in-code.blogspot.com/2010/07/train-model-of-software-development.html），我们需要工具或方法来管理如何我们合并 Pull 请求并构建新版本。
注意：我将使用 Git 术语来解释问题
通过发布序列部署模型，发布按固定的时间表进行，并且功能固定到特定的版本。但此模型的核心思想是，如果某个功能不完整或特别不存在错误，则该功能不会在即将发布的版本中采用，而是计划在以后的版本中使用。
考虑到这一点，我们需要一些方法来管理 Pull 请求并发布以下方面的版本：
可以使用所有功能分支进行构建，以便可以对该构建进行测试（QA）。我们实际上不想将其合并到我们的开发或发布分支中。（为什么？下一点会讨论）
因此，如果某个功能不是零错误（无错误），我们会希望删除该功能。因此，我们实际上只会合并零错误的功能并创建新的发布版本。这样，一个功能就可以很容易地被删除。就发布列车术语而言，该功能不会登上发布列车。
我们的想法：
假设master包含已发布的代码。现在在其之上创建了特征分支 F1、F2、F3。
我们的自动化设置将按时间顺序将这些功能分支（来自具有“已批准”状态的拉取请求）合并到从主分支中删除的临时分支中，并且设置将从该临时分支创建用于 QA 测试的构建。（合并临时分支不会关闭PR）
现在，如果只有功能 F1 和 F3 在零错误日期没有错误，那么 F1 和 F3 的 PR 将被手动合并到 master 中，并且将从 master 创建最终发布版本。
（注：对于第1点，如果出现合并冲突，则由各个分支的开发人员解决。）
有没有 Jenkins 插件或任何其他工具可以帮助我们实现上述目标。请分享一些对此的想法，并提出处理此问题的更好方法。