维护代码时要遵循的最佳实践和经验法则是什么？在开发分支中只有生产就绪代码,或者开发分支中是否有未经测试的最新代码,这是一种好的做法吗？
你们如何维护开发代码和生产代码？
编辑 - 补充问题 - 您的开发团队是否遵循"尽快提交 - 通常 - 甚至是代码包含 - 次要错误或不完整"协议或"提交 - 只有完美的代码"协议,同时将代码提交给开发分支？
当使用 git (flow) 并拥有一个阶段/测试环境时，客户正在对开发的事物进行审查，处理未批准的功能以及已批准的功能的最佳方法是什么？
考虑几个开发人员在冲刺或连续工作流中使用不同功能的场景。功能需要由客户审查，并且为了能够在阶段环境中审查这些功能，它们必须合并到开发分支并部署。
如果，假设已经开发了两个功能，开发团队认为已经完成并推送给开发人员。客户审查它们并批准其中之一。但是现在客户想要将批准的功能发布到生产中。dev 分支现在被未批准的功能代码“污染”，无法推送到生产。
处理这种情况的最佳方法是什么？当然，实际情况要复杂得多。樱桃采摘是一个解决方案还是应该重新考虑整个流程和分支机构的处理？
我们的团队现在正在发布火车部署模型（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 插件或任何其他工具可以帮助我们实现上述目标。请分享一些对此的想法，并提出处理此问题的更好方法。