ios - 如何使用 gitflow 发布一个版本

Question

我将从头开始开发 iOS 应用程序，它只是现有 Android 应用程序的复制。

此应用程序中有 7 个模块(登录、注册...)，客户希望在完成后测试每个模块，以便在所有模块完成并经过良好测试后将应用程序发布到应用商店。

我将在这个项目中使用 git-flow，它有很多分支(master、develop、release、features...)

我的问题是，在这种情况下，当我只有一个版本 (1.0) 将发布到项目结束时，我该如何使用“发布”分支？

当新模块(功能)已处于开发阶段时，我如何管理为模块(功能)交付 IPA 以进行测试？

Answer 1

你想多了。

master中的标签不代表“公开发布”的代码，它代表“已经完成开发和测试”的代码。这些标签是不公开的，它们是帮助开发团队管理代码的标记。

向用户(公共(public)或私有(private))发布代码是一项业务决策，与 git-flow 或任何其他分支模型无关。说某事满足预期要求是一个相关的项目决策。 *

---

因此对于您所描述的情况，我认为以下过程(或类似的过程)是有意义的:

1. 创建 develop 的 feature 分支
2. 完成开发工作(包括代码审查和开发人员测试)
3. 将 feature merge 回 develop
4. 为 QA 测试创建一个 release 分支 **
5. 测试(和修复)完成后，将 release merge 到 master 并将其标记为版本“0.1”
6. merge release 到 develop
7. 对版本“0.2”、“0.3”等重复上述操作。

在 master 中，您将拥有“0.1”、“0.2”等标签。这些代表功能稳定但不适合完整发布的应用程序的不完整版本。最后，当您拥有“0.7”版本(或者这需要多少个周期)时，业务 将做出“此版本代码已完成并适合发布”的决定。然后(并且只有那时)您在 master 中创建标签“1.0”。

future 的开发将使用“1.1”、“1.2”等标签。简而言之，在这个版本控制方案中，第一个数字代表“已发布版本”(由业务确定)，第二个数字代表“开发”迭代”。

---

*显然这两个问题/过程相互作用并相互通知，但这是一个完全不同的话题。 **您不必为每个功能分支都执行此操作，但听起来您是一个人在工作，并且会按顺序进行开发。 merge 多个 feature 分支并创建单个 release 分支用于测试是完全合理的。