GitFlow：先合并到 master 还是在产品发布后合并？

Question

在学习 GitFlow 时，我有一些担忧，但在我读过的任何文档/文章中都没有看到这些担忧。

在某些时候， develop分支上的代码需要部署到 QA/staging 环境并进行严格测试。 因此，使用 GitFlow，您可以从develop中切出一个release分支，然后将release部署到所述暂存环境。

首先，只是想快速澄清一些事情：特定项目/回购第一次经历这个过程，你实际上是从develop分叉/创建这个新的release分支，是吗？ 并且在未来的所有其他时间，您只是将develop合并到release中，是吗？

然后 QA 在暂存环境中测试release分支，一切看起来都很好，我们准备好部署到 prod。 你：

• 部署到 prod，然后将release合并到master中？ ; 或者
• 合并release到master ，然后部署到 prod？

我问是因为在前一种情况下，您似乎需要将release分支部署到 prod，然后部署到 prod，然后合并到master 。 这听起来不错，但通常生产环境和非生产环境并不相同，并且在暂存中运行得很好的代码在生产服务器上第二次启动时会发生阻塞。 我知道 GitFlow 支持热修复分支的概念，但它们是为小修复保留的。 在需要回滚/退出版本的复杂修复的情况下，我们现在将“脏代码”（由于某种原因破坏产品的代码）合并到master中。

在后一种情况下，从合并并放入产品发布请求到产品部署实际发生可能需要数小时甚至数天（尤其是如果您需要让 IT/Ops 参与产品部署） . 在此期间，您有一个master分支，上面写着“功能 X、Y 和 Z 正在生产中”，但实际上并没有。

我想知道 GitFlow 是否真的以某种方式解决了这个问题，或者这两种情况的已知解决方法是什么。

Answer 1

我工作的项目非常混乱，决策在几分钟内就会发生变化，所以我的策略是尽可能拖延软件配置管理决策。

特别是合并到 master：我们只有在部署到生产环境后才合并到 master，并且我们有一封确认电子邮件，表明冒烟测试工作正常。 这样，我们通过管理决策变更、部署回滚、技术问题或任何可能发生的问题的风险来应对混乱。

一开始我们在进入生产之前合并到master，但是最后一分钟的技术问题，回滚，管理决策......给我们带来了很多问题，所以我们改变了策略，并且在过去的3年中一直运作良好年。

如果最终在投入生产后发现一些回归，那就是一个修补程序，必须像这样处理:)

Answer 2

您创建的发布分支是一个短暂的分支，类似于您创建的功能分支。 发布完成后，删除分支。 例如，我会创建一个release/0.1.0分支，完成工作，然后合并。

部署到生产时，我总是从 master 分支中获取代码，这意味着我在部署之前先将 release 分支合并到 master 中。

GitFlow 更多的是关于前进，而不是后退。 因此，为什么要使用修补程序来为已识别的问题创建修复程序。

就进入生产所需的时间而言，这真的不是 GitFlow 关心的问题，我认为它不会在这方面提供太多帮助。 无论您使用哪种分支策略，这对您来说都是一个问题。

Answer 3

你实际上会从开发分叉/创建这个新的发布分支，是吗？

那是正确的。 第一次你唯一的选择是从你的主分支创建release分支，这就是你将部署的 QA/Staging，然后部署到生产。

并且在未来的所有其他时间，您只是将开发合并到发布，是吗？

这取决于。 根据 Git Flow 的描述，release 分支是一个短暂的分支。 它可能只从develop分支出来，并合并到master 。 理论上， release应该在你的 release 完成后合并回develop ，然后被删除。 您应该合并到发布中的唯一内容是hotfix 。 这是一篇关于流程的好文章。

这因一支球队而异。 我曾在完全遵循 GitFlow 描述的团队中工作，而其他人则选择只删除release并从开发中重新创建它，就好像这是第一次一样。

部署到 prod，然后将 release 合并到 master 中？； 或合并发布到主然后部署到生产？

从理论上讲，master 应该始终包含生产就绪代码，而确保这一点的唯一方法是部署到生产的内容正是master 分支中的内容。 也就是说，我们可能无法为您提供特别适合您团队的完美答案。

例如，我目前在一个拥有 CI/CD 管道的团队工作，这让我们别无选择，只能先合并：部署从master自动发生。 我见过一些团队发布的版本相距太远，我更有信心部署release分支，然后再合并。 这避免了部署在release期间出现的人为错误 -> master合并（这可能包括随着时间的推移而产生的令人讨厌的冲突）。

我相信您应该选择最适合您的解决方案，因为 GitFlow 可能无法涵盖所有​​可能的场景和上下文。

Answer 4

从 master 部署适用于小商店。 在必须支持多个版本的情况下，您应该从发布分支进行维护和部署。

Answer 5

在我以前的团队中，分支策略是创建一个发布分支并对发布分支进行最终测试，并在部署之前将发布分支合并到主分支。然后使用主分支进行生产部署。

但我目前的团队使用的是一种不同的方法，即在成功部署产品后，将发布分支部署到生产环境，并将发布分支合并到主分支。 这种方法的好处是确保代码在真实的生产环境中工作，所以我们可以说代码已经在生产中正确运行，然后将发布分支合并到 master，所以 master 中的一切都在现实中工作。 这种方法的另一个优点是，如果部署出现问题，只需使用主分支重新部署即可轻松回滚。

对于以前的方法，我有回滚更改的经验，因为生产环境更复杂，并且在部署之前在非生产环境中没有发现问题，所以我需要 rebase/revert master 分支中的更改，这意味着 master 分支是在我做 rebase/revert 之前已经坏了:(

我喜欢在发布分支上发布并在产品部署后将其合并回母版的东西很容易回滚，并通过在实际生产环境中运行代码来确保母版中的代码正确，而不仅仅是在非产品环境中。

最后，它仍然取决于哪种方法适合您的项目/团队。

Answer 6

我认为您首先部署然后合并的原因是因为在您的 CI/CD 管道中，您可以在部署后进行一些冒烟测试，如果事情不稳定，您可以通过部署最初在 master 分支中的内容来进行还原，由于您的管道失败，因此不会发生与 master 的合并。

但是，如果你先合并然后部署，那么恢复可能会很棘手，因为你必须恢复合并......所以我认为从发布部署是有意义的，如果事情稳定，那么你合并到 master。