需要拉取请求通信策略

Question

进行基于主干的开发以实现持续部署。这就是我们的分支策略。

ma​​ster > 制作中的内容

发布 > 测试通过并由 CI 服务器创建发布点

dev > 来自开发团队的每日合并。

如果我们考虑从发布到主阶段执行拉取请求。 这种方法的优点和缺点是什么？我们如何与他们想在 dev 分支进行 PR 的开发团队进行沟通？

Answer 1

我真的没有答案，但认为问题的背景值得进一步讨论。

如果您正在进行持续部署，那么我不确定发布分支的用途。它似乎重复了两者的目的：

• 'master'：正在部署/发布的代码
• “开发”集成功能 分支，但尚未准备好发布

或者，您是否使用它来对里程碑或计划中的主要版本（即 Release/1.0、Release/2.0）进行分组，例如迷你主分支。
我不会考虑这种持续交付（可能是部署），但如果您的项目需要分阶段发布而不是持续交付，它肯定是一种有效的模式。

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

下一个考虑因素是每个额外的分支都会为开发人员增加时间和复杂性。合并、拉取请求、等待 CI 运行等都不是免费的，因此将分支策略的复杂性降低到您需要的最低限度是一个不错的目标。

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