ios - 在考虑 App Store 审核时间的同时遵守 git 流程规则

Question

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

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

我们在其发布分支中 merge 后，从主分支上的标记中发布此 BETA。然而，git flow 规定 master 分支必须反射(reflect)当前生产中的内容。现在，在实际投入生产之前总会有等待时间(所以我们不能不破坏 git 流模型)，但是如果在此 BETA 中发现严重的错误，我们会将其从审查队列中删除，这意味着它不会被发布，现在 master 上的最新提交并不能反射(reflect)生产中的内容。

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

Answer 1

We release this BETA from a tag on the master branch after merging in its release branch. However, git flow dictates that the master branch must reflect what is currently in production.

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

我的意思是，release 分支旨在准确地跟踪正在评估的 release candidates 的生命周期，无论这意味着内部测试、beta 用户测试还是，为什么不，App Store 审核流程。

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

• 如果您遭到拒绝或有任何问题，您仍然可以对其进行调整并从同一 release 分支重新提交新候选人。
• 一旦获得 App Store 批准，您就可以关闭 release 分支(它将所有更改 merge 到 master 和 develop)并将其设置为在 App Store 上线。