管理跨多个分支和计划的应用程序版本的核心数据模型迁移
优点：简单且非常适合具有简单数据模型的小型项目，或者具有很少因发布而变化的数据模型。 对于非常小的项目团队（也可以由一个人来管理所有事情）来说，它也很棒。
缺点：难以管理大型团队或数据模型经常更改或团队规模较大的复杂项目。
如果需要数据模型更新作为热修复程序或在项目的更高分支上，则该更新将必须“波纹化”所有下游分支。 此外，在功能分支上进行更新然后合并回主分支可能会与活动开发中的其他功能冲突。 在整个过程中合并更新可能需要大量的手动工作，并将更新手动合并到许多Core Data模型文件中。 这项工作可能非常令人困惑，难以遵循，并且犯下一个很小的，未引起注意的错误的风险很高，该错误将来会使生产发布应用程序中毒。
选项2）每个发行版本都有其自己的Core Data模型版本文件，因此Beta，Develop和Alpha都具有不同的模型版本说明符。 每个功能分支都共享其父分支的模型，并且不添加模型版本文件。 功能分支仅修改现有模型版本文件。
优点：具有比选项1更大的可伸缩性。一次仅需一次将更改迁移到上游，而在选项1中，可能需要通过几个模型更新文件来使更改产生变化。 数据模型未版本化，可以直接链接到应用程序的特定版本。 更可预测和可理解。 确定数据模型问题以及从错误中恢复要容易得多。
缺点：必须与客户和其他团队成员进行沟通（禁止上空），因为每次更新数据模型时，都必须删除并重新安装开发应用程序以合并新的数据模型。
我在网上找到的所有资源都只提到了如何将核心数据模型从一个版本迁移到另一个版本，这与上面的选项1最相似，但是在过去的几个月中，随着项目的发展，选项1的弊端真正开始了付出代价 从那时起，我发现遵循选项2带来的麻烦最少，并使Core Data模型的git合并非常直接且相对简单。