如何将 gitflow 用于一个版本

Question

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

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

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

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

以及如何管理为模块（功能）交付 IPA 以在新模块（功能）已处于开发阶段时进行测试？

Answer 1

你多虑了。

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

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

---

因此，对于您描述的情况，我认为以下过程（或类似过程）是有道理的：

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

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

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

---

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