如何在软件开发的火车模型中管理功能或拉取请求？

Question

我们的团队现在正在发布火车部署模型（http://thinking-in-code.blogspot.com/2010/07/train-model-of-software-development.html），我们需要工具或方法来管理如何我们合并 Pull 请求并构建新版本。

注意：我将使用 Git 术语来解释问题

通过发布序列部署模型，发布按固定的时间表进行，并且功能固定到特定的版本。但此模型的核心思想是，如果某个功能不完整或特别不存在错误，则该功能不会在即将发布的版本中采用，而是计划在以后的版本中使用。

考虑到这一点，我们需要一些方法来管理 Pull 请求并发布以下方面的版本：

1. 可以使用所有功能分支进行构建，以便可以对该构建进行测试（QA）。我们实际上不想将其合并到我们的开发或发布分支中。（为什么？下一点会讨论）

2. 因此，如果某个功能不是零错误（无错误），我们会希望删除该功能。因此，我们实际上只会合并零错误的功能并创建新的发布版本。这样，一个功能就可以很容易地被删除。就发布列车术语而言，该功能不会登上发布列车。

我们的想法：

假设master包含已发布的代码。现在在其之上创建了特征分支 F1、F2、F3。

1. 我们的自动化设置将按时间顺序将这些功能分支（来自具有“已批准”状态的拉取请求）合并到从主分支中删除的临时分支中，并且设置将从该临时分支创建用于 QA 测试的构建。（合并临时分支不会关闭PR）

2. 现在，如果只有功能 F1 和 F3 在零错误日期没有错误，那么 F1 和 F3 的 PR 将被手动合并到 master 中，并且将从 master 创建最终发布版本。

（注：对于第1点，如果出现合并冲突，则由各个分支的开发人员解决。）

有没有 Jenkins 插件或任何其他工具可以帮助我们实现上述目标。请分享一些对此的想法，并提出处理此问题的更好方法。

Answer 1

因此，我们实际上只会合并零错误的功能并创建新的发布版本

嗯...问题是合并的结果（意味着“0 bug 功能分支”合并）可能会导致一些 bug！
0-bug 功能分支（当单独开发时）在集成时可能会出现错误。

遵循发布列车模型的一般 git 工作流程是gitworkflow（一个词）

这个想法是将下一个版本所需的分支合并到中间瞬态集成分支（您可以称为“集成”或“开发”或“下一个”...）。
该分支是为每个新版本重新创建的，并允许在集成中（一起）测试这些功能分支。

然后，您只合并到master下一个版本中真正想要的内容。
您不将分支合并integration到master. 只有feature分支机构。

请参阅此处和此处的更多内容。
我在这里回答了有关该工作流程的问题。