在公司内部同步任务

我们的iOS分支模型

团队越大，当多个人在同一个代码库上工作时，发生问题的可能性就越大。 为了保证无障碍和协作的工作流程，仅知道您的git命令并不会削减它。 因此，有必要定义一个分支模型，以适应内部流程并限制从一群同步工作的人中出现的复杂性。

在Wolox，我们的目标是使开发人员更轻松地管理分支机构，同时在将构建发送给质量保证（QA）部门进行测试时，还节省了时间。

结果？ 通过实施此模型，我们的产品质量得以提高，因为质量保证可以使用更完整的方法进行测试。

史诗（用户）故事

我们在iOS部门Wolox的分支模型基于Epics（即用户故事）的概念。 存在此类概念的几种不同定义，但是在Wolox，我们将它们定义为一组任务，这些任务具有完整的功能，可以为最终用户增加价值 。 史诗只有在其包含的所有任务完成后才有意义。

质量保证（QA）

与史诗打交道的主要优点之一是简化了开发人员和测试人员的质量检查流程。 在此模型中，一旦完成，我们就会向质量检查小组发送史诗。 这样，开发人员就不必为每个任务构建一个.ipa，从而节省了时间，并且质量检查团队可以测试其全部功能及其组件之间的交互。 这简化了两端的过程，并使测试人员的工作更有效，从而提高了产品的整体质量 。

我们的分行

主

在我们的master分支中，我们找到了最新版本。 该分支应始终包含工作和可交付的代码。

开发人员

开发分支从母版分支出来。 在这里，我们可以找到质量检查已批准的史诗。 在Wolox，我们使用Scrum，因此在每个sprint结束之后，在检查了此处合并的不同史诗是否相互兼容之后，我们将此分支合并到master。 根据您的方法或项目的具体情况，一旦向客户显示进度（内部或外部），您也可以合并以掌握。 请记住，master必须始终包含正确运行的代码，因此在合并时请谨记。

史诗-{史诗名称}

每个史诗分支都包含已被代码审查且提交请求已被批准的提交。 史诗般的所有任务通过我们的代码审查流程后，便会生成.ipa并将其发送给质量检查人员。 记住要先从开发者那里重新定位！

*避免合并错误的一个好技巧是拥有受保护的分支。

{epic name}-{feature name}

每个功能都从其对应的史诗分支中分支出来。 在这里，开发人员进行必要的提交以实现任务或功能。 完成后，开发人员将史诗分支作为目标分支，从而打开一个新的请求代码审查请求。

让我们玩这个…

想象一个已经有几个发行版的项目，其中的master和dev是最新的。 在下一个冲刺计划中，我们决定开发三个新功能：

• 查看重新设计
• 新视图（视图B）
• 实施推送通知

因此，我们将根据dev创建3个新分支：

• 史诗般的屏幕重新设计
• 史诗般的画面B
• 史诗般的推送通知

我们必须为每个史诗选择一个所有者，然后由他负责在存储库中创建新分支，以便团队中的每个成员都拥有相同的分支。 此人还将在必要时创建测试计划，并在史诗完成后构建.ipa并将其发送给QA测试人员。 尽管该史诗具有所有者，但这并不排除其他开发人员在功能分支中从事史诗的工作。

同样，在sprint计划中，我们可以为每个史诗定义任务，或将任务留给每个开发人员或一组开发人员。 这些将是我们的epic-screen-B分支的四个功能：

• screen-B-设计，我们在其中实现视图和前端
• screen-B –后端，我们在其中开发后端并连接到外部服务。 在Wolox，后端并不意味着Web后端服务。 这是我们管理逻辑和非UI代码的地方。
• screen-B –将此屏幕与应用程序现有流程连接的流程。
• screen-B –我们开发屏幕所包含的表视图的表，因为它过于复杂而无法包含在前端或后端分支中。

每个团队都可以决定是让一个还是多个开发人员来制作每部史诗。

一旦开发了screen-B-table，就向epic-screen-B打开一个新的Pull Request。 在这里，代码审阅者进行注释，而开发人员进行更正。 完成此过程后，必要的事情来了又去了，审阅者批准了Pull Request，并将分支合并到epic-screen-B， 从而使此功能可用于从事该史诗的所有开发人员，并加快了该史诗的开发。该应用程序。

合并所有四个功能分支后，我们将创建一个.ipa并将史诗般的屏幕B发送给质量检查人员，

在将该分支重新定为开发人员之后。 在这里，负责此史诗的质量检查工程师会标记他们发现的错误。 一旦解决了这些问题（在史诗分支中添加了提交），并且一旦在新的“拉取请求”中查看了更改，便将新的构建提交给QA。 重复此过程，直到QA同意为止。 只有这样，史诗般的屏幕B才合并到dev中。

在sprint结束时，将三个新的史诗合并到dev中，我们为客户提供了已实现成果的演示。 客户批准我们的工作后，我们会将开发人员合并为主人。

发布新应用（例如新的App Store或Test Flight提交）时，我们会在master分支中创建一个标签 ，其中包含发布版本。 如果需要，这将使将来的回滚更加容易，因为这些标记表明该应用程序正在运行且可交付使用。

错误呢？

随着时间的流逝，我们发现在某些情况下问题不属于史诗。 这在错误修复和技术问题中很常见。 在Wolox，我们通常直接从dev分支出这类任务，避免在单个问题上使用史诗。 我们仍然尊重我们的方法，因此在合并之前，我们会通过请求请求对代码进行审查，并提交构建以供质量检查人员审查。

最后的想法

我希望这能给您概述我们在Wolox的工作方式。 我们在进行了几次更改，讨论和组织会议之后，已经开发了这种分支模型，目前，它适合我们的需求，并允许我们有效地进行协作。

我们发现我们的速度急剧提高，产品的整体质量得到了改善，我们的开发人员和测试人员对该模型更加满意。 我们的计划会议更加有效，我们的流程也更加高效。

但是，这绝不是严格的模型。 我们使用的想法可以并且应该适应您的需求和过程 。 希望您在开发分支模型时可以采纳其中的一些想法，并希望在评论中阅读您的观点和想法！

附加资源：成功的分支模型