GitFlow：先合并到主版本还是在产品发布后合并？答案

【问题标题】：GitFlow: merge to master first or after prod release?GitFlow：先合并到主版本还是在产品发布后合并？
【发布时间】：2021-08-07 08:01:13
【问题描述】：

在学习 GitFlow 时，我遇到了一些我在阅读过的任何文档/文章中都没有解决的问题。

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

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

然后 QA 测试了 staging env 上的 release 分支，一切看起来都很好，我们已经准备好部署到 prod。你：

部署到产品并然后将release合并到master？ ; 或
将release 合并到master 并然后部署到产品？

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

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

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

【问题讨论】：

标签： git github git-flow

【解决方案1】：

我从事的项目非常混乱，决策在几分钟内改变，所以我的策略是尽可能拖延软件配置管理决策。

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

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

如果最终在投入生产后发现了一些回归，那就是hotfix，必须这样处理:)

【讨论】：

这种方法的问题在于，在合并到 master 和 tagging 之后，post-merge 标记本质上指向了与您用于部署的提交不同的提交。这会破坏可重复的构建。
对不起，我没明白你的意思。你能详细说明一下吗？您所说的“合并后标签”是什么意思，它的目的是什么？
每个 gitflow，一旦你将发布分支合并到 master，你就在 master 分支中标记它。 see here。在您的情况下，您的生产部署来自最后一次绿色提交（合并之前），而标签指向不同的青色提交。如果您想在稍后的某个时间重复完全相同的部署，则从标记部署不起作用，因为您是从不同的提交进行部署。
那么，您可以标记绿色提交。我不认为这样做有什么大不了的。最后，Git 关心的不是分支，而是图，所以我们处理的是提交图。如果这里重要的是标记在生产中部署的更改，那么无论分支如何，您都可以标记发送到生产的提交。完成此操作后，此提交可以合并到 master 中，其余的开发将 master 到它们的分支中。
@BornToCode 一旦代码投入生产，就没有回头路了。这里的问题是，通过“拖延”决策，如果您尽可能推迟合并到 master，您将保持主分支的原始状态，避免主分支上出现丑陋的还原或补丁。

【解决方案2】：

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

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

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

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

【讨论】：

不确定这应该是答案，我们缺少在发布之前或之后合并的理由或优缺点。
在部署之前合并的一个巨大优势是几乎不可能错过最近合并回主服务器的任何错误修复（如果有的话），因此会产生回归事件。出于这个原因，我认为这是最好的方法。
我认为这是一个巨大的劣势。是否不会在旧版本中修复任何修补程序并合并到主版本，然后传播到任何候选版本并进行开发？否则，候选版本也将表现出回归。因此，不会被“释放”。您是说任何活动的发布迭代都必须合并到 first，才能获得该修补程序，对吗？

【解决方案3】：

实际上，您将从develop 分支/创建这个新的发布分支，是吗？

没错。第一次时，您唯一的选择是从主分支创建 release 分支，这就是您将部署用于 QA/Staging 以及稍后部署到生产环境的内容。

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

这取决于。根据 Git Flow 的描述，发布分支是一个短命的分支。它可能仅从develop 分支出来，并合并到master。理论上，release 应该在您的发布完成后合并回develop，然后删除。您唯一应该合并到版本中的是hotfix。这是关于流程的一个很好的清洁article。

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

部署到 prod，然后将 release 合并到 master？或者合并发布到master，然后部署到prod？

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

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

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

【讨论】：

【解决方案4】：

从 master 部署对于小型商店来说很好。如果您必须支持多个版本，您应该从发布分支进行维护和部署。

【讨论】：