拉请求通信策略需要

Question

做基于trunk的开发到实现持续部署。这是我们的分支策略。

主>什么活在生产

发布>测试通过并释放CI服务器

开发>从开发团队每天创建的合并点。

如果我们考虑从发布到主阶段执行pull请求。 该方法有什么优点和缺点？我们如何与开发团队沟通，他们想在开发分支做PR？

Answer 1

我真的不知道答案，但认为这个问题的背景下值得进一步讨论。

如果您正在进行连续部署，那么我不确定发布分支的目的。这似乎是重复的两种目的：

• “主”：代码部署/发布
• “发展”综合功能 分支机构，但不准备释放

或者，是你使用它来分组里程碑或计划的主要版本（即版本/ 1.0,版本/ 2.0），就像一个小型主分支。
我不会考虑这种持续交付（部署，也许），但它肯定是一个有效的模式，如果您的项目需要分阶段发布而不是持续交付。

同样考虑您的CI设置以及它如何与您的分支机构整合也很重要。它不是部署到Production的源代码，而是来自CI系统的构建工件。考虑这可能会简化您的分支模型。 如果你想回滚，你不想从源重建应用程序，你想重新部署先前版本的预构建工件。同样，如果您的构建已通过所有测试并准备发布 - 希望已在您的预生产环境中运行 - 您不希望将其合并到不同的分支，重新构建它，然后部署新的构建 - 您使用经过测试的构建。

下一个考虑因素是每个附加分支都会给开发人员增加时间&的复杂性。合并，拉取请求，等待CI运行等都不是免费的，因此将分支策略的复杂性降低到所需的最小值是一个很好的目标。

要回答您关于PR到哪里的问题，您是否认为“Develop”作为主线，并试图保持其稳定性并始终在工作？
如果是这样，那么从功能到开发的PR是关键集成。然后开发将被构建，测试并部署到您的测试环境中。
从那时开始分支（即创建一个Release分支）然后被认为是好的。 将您的测试环境中的工件提升为生产，无需重新构建，可能会取消您的某个分支机构的需求。