学习GitFlow，我有些担心，我在任何我读过的文档/文章中都没有看到。
在某些时候，develop分支上的代码需要部署到QA /暂存环境并严格测试。因此，使用GitFlow，您可以从release中删除develop分支，然后将release部署到所述暂存环境。
首先，只是想快速澄清一些事情：第一次特定项目/回购通过这个过程，你实际上是从{{1}分支/创建这个新的release分支}，是？在未来的所有其他时间，您只需将 develop合并到develop，是？
然后QA测试staging env上的release分支，看起来都很好，我们已准备好部署到prod。你：
release合并到release？ ; 或 master合并到release和然后部署到prod？我问，因为在前一种情况下你似乎需要将master分支部署到prod，然后部署到prod，然后合并到release。这听起来还不错，但是prod和非prod环境通常并不完全相同，而且在praging服务器上激活的第二个代码在staging chokes中运行得非常好。我知道GitFlow支持修补程序分支的概念，但它们保留用于小修复。在需要回滚/撤销发布的复杂修复的情况下，我们现在有＃34;脏代码＆＃34; （由于某种原因打破prod的代码）合并到master。
在后一种情况下，可能需要数小时甚至数天（特别是如果您需要让IT / Ops进行生产部署）从您合并并提交产品发布请求到产品生产时部署实际发生。在这段时间内，你有一个master分支，表示＆＃34;特征是X，Y和Z在生产中＃34;但事实并非如此。
我想知道GitFlow是否真的以某种方式解决了这个问题，或者两种情况下的已知解决方法是什么。
答案 0 :(得分：8)
我工作的项目非常混乱，决策在分钟的情况下发生变化，因此我的策略尽可能地拖延软件配置管理决策。< / p>
特别是，合并到主人：我们只在我们部署生产后合并为主人并且我们有一封确认电子邮件，冒烟测试罚款。这样我们就可以通过管理决策变更的风险，部署中的回滚，技术问题或任何可能发生的问题来实现混乱。
一开始我们在投入生产之前合并为主人，但技术问题，回滚，管理决策在最后一分钟......给我们带来了很多问题，所以我们改变了策略，并且它一直工作得很好过去3年。
如果最终在生产后发现了一些回归，那就是修补程序，必须像这样处理：）
答案 1 :(得分：4)
您创建的发布分支是一个短暂的分支，类似于您创建的功能分支。发布完成后，删除分支。例如，我将创建一个release/0.1.0分支，完成工作，然后合并。
在部署到生产时，我总是从主分支中获取代码，这意味着我在部署之前首先将发布分支合并到主分支中。
GitFlow更多的是前进而不是后退。因此，为什么使用修补程序为已识别的问题创建修补程序。
就进入生产所需的时间而言，这并不是GitFlow关注的问题，我认为它不会在这方面提供太多帮助。无论您使用哪种分支策略，这都将成为您的问题。
答案 2 :(得分：4)
您实际上是从development分支/创建了这个新的发行分支，是吗？
是正确的。唯一的选择是，第一次在主分支上创建一个release分支，这就是您将要进行质量检查/登台，然后再用于生产的部署。
在将来的所有其他时间，您只是将开发合并到发行版中，是吗？
这取决于。根据Git Flow的描述，发布分支是短暂的分支。它可能仅从develop分支出来，并合并到master中。从理论上讲，release应该在发布完成后重新合并到develop中，然后删除。您应该合并到发布中的唯一内容是hotfix。这是关于流程的一个很好的article。
每个团队的情况各不相同。我已经在完全遵循GitFlow描述的团队中工作，其他团队则选择只删除release并从开发中重新创建它，就像第一次一样。
部署到产品，然后将发行版合并到主版本中？要么 将发行版合并到主版本，然后部署到产品？
从理论上讲，master应该总是包含随时可用于生产的代码，并且唯一可以确保部署到生产中的是完全准确的代码在master分支中。也就是说，对于您的您的团队特别有用，我们可能无法为您提供完美的答案。
例如，我目前在一个具有CI / CD管道的团队中工作，这使我们别无选择，只能先合并：部署从master自动进行。我见过一些团队之间的发布版本相距太远，因此更有信心部署release分支，然后进行合并。这样可以避免部署在release-> master合并期间发生的人为错误（该错误可能包括随着时间的推移而累积的令人讨厌的冲突）。
我相信您应该选择最适合自己的解决方案，因为GitFlow可能无法涵盖所有可能的情况和上下文。
答案 3 :(得分：1)
从 master 部署适用于小商店。如果您必须支持多个版本，则应从发布分支进行维护和部署。