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