GitFlow - 我怎样才能实现拉取请求/部署的某些部分的持续部署，即使其他部分没有通过测试？

Question

我们有3个环境：

在上面的案例中，当部署发生在一堆时，它工作正常，但是当我们想要做持续部署时，它被阻塞了。

示例：功能 1、2、3 已准备好进行登台 QA，并且登台已合并到发布中。现在验收测试人员只接受了功能 3 并重新设计了功能 1 和 2。在这种情况下，直到功能 1 和 2 得到修复，整个部署都被阻止了。

一个解决方案是：Cherry-pick 功能 3 的提交并将其推送到 main.

当有多个提交时，这非常复杂，并且可能还有合并提交和暂存。而且，这非常耗时。

有没有什么方法可以自动化或加速这个过程，以实现对被接受的拉取请求的持续部署？

Answer 1

不要合并集成分支（将多个功能分支集成在一起的分支）：正如您所描述的，在每个分支中获得正确的功能集变得非常复杂。

集成分支（QA、暂存、发布）是您要合并的长寿命分支to，而不是from。

将特性分支合并到 QA，然后将那些相同的特性分支（但只有准备好的分支）合并到暂存。
并且只合并那些准备发布的。

我之前将这个过程描述为gitworkflow（一个词）

话虽如此，正如 Daniel Mann 评论的那样，集成分支应该 not 代表部署阶段。

一个部署与源代码控制是正交的，并且通过一系列阶段以代码的一个固定状态来部署同一个工件。

Answer 2

This question is tagged with Git Flow，基于此，您的

staging

分支可能旨在像 Git Flow 中的

develop

分支，但您使用它的方式略有不同。

在 Git Flow 中，

develop

分支旨在像其他流程中的

master

或

main

分支，从某种意义上说，当您可以假设您非常确定代码时，您将代码合并到

develop

中准备投入生产。从那里发布分支用于验证您的假设是否正确。发布分支是为待发布的版本创建的，用于进行额外的测试，以防万一。发布分支只是为您提供一个分支，以便在需要时进行错误修复，而其他功能则合并到

develop

中，用于待定版本之后的下一个版本。这种无需冻结代码即可同时开发新功能，同时强化待定发布的功能，是使用 Git Flow 的主要好处。然而，除非发布强化周期非常短（比如，可能少于几个小时，但很可能少于一天），否则 Git Flow 通常与 CI/CD 实践不一致。

原来你没有按照 Git Flow 打算使用

staging

分支的方式使用你的

develop

分支。如果您还没有决定要在即将发布的版本中包含哪些功能，那么它们还没有准备好合并到

develop

中；你需要用不同的方式来解决这个问题，或者考虑一下 Git Flow 可能不是最适合你的工作流程。您可以使用功能标志（意味着所有内容都合并到

develop

中，但是可以在

release

分支上切换配置以确定打开的内容），或者您可以简单地恢复合并到

develop

甚至在

 release

分支机构。在您的确切情况下，有 3 个功能进入

release

并且您当时决定只希望发布其中一个，我建议您简单地恢复不需要的功能的 2 个合并。您始终可以稍后将它们添加回去（通过还原还原提交，或重写提交 ID 并重新合并它们）。

请注意，如果您的情况不是真正的例外并且经常发生，那么我强烈建议使用 VonC 的回答中提到的 gitworkflow。请注意，它甚至不必是“非此即彼”的决定。在我组织中的一个大型存储库中，我们实际上同时使用了两者：我们有一个

next

分支，我们在其中进行集成测试，一旦这些功能在测试环境中得到验证，我们就将它们合并到

develop

中在我们的 Git Flow 策略中。使用“gitworkflow”要记住的最重要的事情是你应该定期将

next

分支重置为你的主要开发分支，这在某些流程中通常是

main

，但如果你'我们正在使用混合模型。