在考虑 App Store 审查时间的同时遵守 git flow 规则答案

【问题标题】：Adhering to git flow rules while taking the App Store review times into account在考虑 App Store 审查时间的同时遵守 git flow 规则
【发布时间】：2016-10-26 21:16:11
【问题描述】：

我们已经在我们的 iOS 项目中愉快地使用 git flow 有一段时间了。然而，今天我突然想到了一些事情，这意味着我们实际上没有遵循 git flow 规范。

当我们开始对某个版本进行最终测试时，我们会向我们组织内的数百人发布一个 BETA 版本。现在，这个 BETA 基本上是一个发布候选版本，因为在这种情况下，它已经为 App Store 发布做好了准备。由于有 7 天以上的审核时间，我们总是将此 BETA 上传到 iTunes Connect 并将其设置为等待审核。

在合并到其发布分支后，我们从主分支上的标签发布此 BETA。但是，git flow 规定主分支必须反映当前生产中的内容。现在，在它真正投入生产之前总会有一个等待时间（所以我们不能不破坏 git 流模型），但是如果在这个 BETA 中发现严重的错误，我们会将它从审查队列中删除，这意味着它不会被释放，现在 master 上的最新提交并不能反映生产中的内容。

您如何在工作流程中解决这个问题？

【问题讨论】：

标签： ios git continuous-integration continuous-deployment git-flow

【解决方案1】：

在合并到其发布分支后，我们从主分支上的标签发布此 BETA。但是，git flow 规定主分支必须反映当前生产中的内容。

那么，如果 BETA 目前尚未投入生产，您为什么要这样做？ :)

我的意思是，release 分支正是为了在评估时跟踪候选版本的生命周期，无论这意味着内部测试、beta 用户测试还是应用程序测试商店审核流程。

因此，我建议您在 BETA 的整个生命周期中保持release 分支打开，并从那里构建提交到 App Store 的版本：

如果您被拒绝或有任何问题，您仍然可以调整它并从同一 release 分支重新提交新的候选人。
获得 App Store 批准后，您可以关闭 release 分支（合并对 master 和 develop 的所有更改）并将其设置在 App Store 上。

【讨论】：

感谢您的回复。我们一直在讨论你的建议，但坚持 git flow 也意味着我将发布分支中的合并提交标记为 master 并使用它来构建生产构建，但这个提交不会是生产的提交build 已编译，因此该标签变得毫无意义。
我将此流程用于测试版和应用商店版本，效果很好。我认为，这应该被标记为使用 git-flow 处理 beta/appstore 发布周期的正确答案。
@mattsson 我认为您对“坚持 git flow”的解释过于“纯粹”。请记住，git flow 是作为一种在 sw 中处理发布管理的实用方法而诞生的，它以包的形式分发，merge commit 只不过是指向 2 个父级的提交。代码方面，master 中的 merge commit 仍然具有与 release 分支中完全相同的内容。
@HugoFerreira 够了，谢谢你的解释，我想我们实际上会采用这个过程。