我将从头开始开发 iOS 应用，它只是对现有 Android 应用的复制。
此应用中有 7 个模块（登录、注册...），客户希望在完成后测试每个模块，以便在所有模块完成并经过良好测试后将应用发布到应用商店。
我将在这个项目中使用 git-flow，它有很多分支（master、develop、release、features...）
我的问题是，当我只有一个版本 (1.0) 将发布到项目结束时，我该如何使用“发布”分支？
当新模块（功能）处于开发阶段时，我如何管理为模块（功能）交付 IPA 以进行测试？
【问题讨论】：
你想多了。
master 中的标签不代表“已向公众发布”的代码，它代表“已完成开发和测试”的代码。这些标签不公开，它们是帮助开发团队管理代码的标记。
向用户（公共或私人）发布代码是一个与 git-flow 或任何其他分支模型无关的业务决策。说某事符合预期要求是一个相关的项目决定。 *
所以对于你描述的情况，我认为以下过程（或类似的东西）是有道理的：
develop 的feature 分支
feature 合并回develop
release 分支**release 合并到master 并将其标记为版本“0.1”release 合并到develop
在master 中，您将有标签“0.1”、“0.2”等。这些代表应用程序的不完整版本，它们功能强大且稳定，但不适合完整发布。最后，当您拥有“0.7”版本（或这需要多少个周期）时，企业 将做出“此版本代码已完成并适合发布”的决定。然后（并且仅在那时）您是否在master 中创建标签“1.0”。
未来的开发将使用“1.1”、“1.2”等标签。简而言之，在这个版本控制方案中，第一个数字代表“发布版本”（由业务确定），第二个数字代表“开发迭代”。
*显然这两个关注点/过程会相互作用并相互通知，但这是一个完全不同的主题。
**您不必为每个功能分支都这样做，但听起来您是在单独工作，并且将按顺序进行开发。合并多个feature 分支并创建一个release 分支进行测试是完全合理的。
【讨论】：