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

在学习GitFlow时，我有一些顾虑，但在我读过的任何文档/文章中都没有提到

在某个时候，

develope

分支上的代码需要部署到QA/staging环境中，并进行严格的测试。因此，使用GitFlow，您将

发布版

从

开发版

中剪掉一个分支，然后将

发布版

部署到所述登台环境中

首先，我想很快澄清一点：当某个特定项目/回购第一次经历这个过程时，您实际上将从

develope

，yes派生/创建这个新的

release

分支？在未来的所有其他时间里，您只需将

开发

合并到

发布

，是

然后QA在staging env上测试

release

分支，看起来一切正常，我们准备部署到prod。您是否：

• 部署到prod，然后将

  发布

  合并到

  主控

  或
• 合并

  release

  到

  master

  ，然后部署到prod

我这样问是因为在前一种情况下，您似乎需要将

发布

分支部署到prod，然后部署到prod，然后合并到

主

。这听起来不错，但通常prod和非prod环境并不完全相同，在暂存中运行良好的代码会在prod服务器上启动时阻塞。我知道GitFlow支持热修复分支的概念，但它们是为小修复保留的。对于需要回滚/回退版本的复杂修复，我们现在将“脏代码”（由于某种原因破坏prod的代码）合并到

master

在后一种情况下，从合并并提交产品发布请求到产品部署实际发生的时间，可能需要数小时甚至数天（特别是当您需要it/Ops参与产品部署时）。在这段时间里，你有一个

master

分支，上面写着“特性X、Y和Z在prod中”，但实际上它们不是

---

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

您创建的发布分支是一个短期分支，类似于您创建的功能分支。发布完成后，将删除分支。例如，我将创建一个

release/0.1.0

分支，完成工作，然后合并

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

GitFlow更多的是向前移动，而不是向后移动。因此，为什么使用热修复程序为已识别的问题创建修复程序

---

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

我工作的项目非常混乱，决策在分钟内改变，因此我的策略是尽可能拖延软件配置管理决策

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

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

如果最终在投入生产后发现某种回归，则这是一个修补程序，必须这样处理：）

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

这是正确的。第一次，您唯一的选择是在主分支之外创建

发布

分支，这就是您将为QA/Staging部署的内容，稍后将部署到生产中

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

视情况而定。根据Git流的描述，发布分支是一个短暂的分支。它可以仅从

开发

分支，并合并到

主

。理论上，

release

应该在发布完成后合并回

develope

，然后删除。您唯一应该合并到发行版中的是

修补程序

。这是一个很好的关于流动的清洁

这因团队而异。我曾经在完全遵循GitFlow描述的团队中工作过，还有一些团队选择删除

发布
并从develop中重新创建它，就好像这是第一次一样

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

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

例如，我目前在一个拥有CI/CD管道的团队中工作，这让我们别无选择，只能在之前进行合并：部署将从
master
自动进行。我见过一些团队发布的版本相距太远，因此更自信地部署
发布
分支，然后合并。这样可以避免部署在
发行版
->
主版
合并期间发生的人为错误（这可能包括在t