两个iOS应用程序的Git存储库结构，其中一个应用程序与另一个应用程序有很大差异

情况如下。我在一家公司工作，该公司最初只有一个iOS应用程序。现在，该公司有兴趣创建第二个iOS应用程序，它共享大部分相同的代码库。最初的应用程序不是为了可重用而编写的，因为当时不知道会创建第二个类似的应用程序。将来，可能会有更多类似的应用程序构建在现有的代码基础上

我们正试图确定如何继续维护源代码的“最佳”选项。因此，我们正在考虑的一些选项包括带有共享库的单个存储库、一个用于共享库的存储库和一个包含所有iOS应用程序的存储库、一个用于共享库的存储库和每个iOS应用程序一个存储库，还有一个问题是，如果使用多个存储库等等，是否使用git子模块

目前，这两个应用程序+库都位于一个git存储库中。这样做的一个优点是，开发人员可以签出单个存储库的提交，并期望生成产品，而不必担心更新多个存储库。基本上，开发人员不必担心多个存储库需要彼此同步移动，或者需要特定的存储库组合才能使构建工作。开发人员也不必担心其他开发人员可能记得提交一个存储库，但没有提交另一个存储库的情况

以下是我考虑过的一些事情：

子模块 我以前使用过子模块，但我不是专家。我的理解是，包含子模块的“超级”存储库还存储对子模块的特定提交的引用。这在一定程度上是为了确保多个存储库（即应用程序+库）能够同步移动，尽管我猜在需要手动从子模块中提取更改时仍然存在一些问题。此外，如果开发人员碰巧忘记推送其更改，并且超级存储库引用了子模块提交，则子模块提交无法用于拉取

子模块的一个好的方面是，它在库和碰巧使用库的应用程序之间创建了更强的语义分离。我不确定这在实践中是否有用

单一存储库 如前所述，这是我们目前正在做的事情。两个应用程序+共享库代码都在一个存储库中。最令人担忧的是，在项目1和项目2与库之间隔离更改的能力相对不存在。例如，有人在一次提交中对某些库代码和某些应用程序代码进行了更改。然后，另一个开发人员只想更改库代码

单一存储库的一个优点是，所有内容都是同步运行的——没有人需要担心保持多个存储库版本的匹配。如果使用XCode工作区，甚至可以跨两个应用程序进行重构

分支 另一种选择是在单个或多个存储库中使用某种分支模型来管理代码

---

最终，我们只是想找出一个好的模型，用于管理两个或多个iOS应用程序以及共享库代码。这可以通过多个存储库、子模块、分支模型或其他方式实现。关于各种选项的利弊有什么一般性建议吗？

使用子模块。你不需要成为专家，因为它们真的很容易使用。尤其是与类似SourceTree的GUI结合时。我和你的情况完全一样，我就是这么做的。如果您试图提交子模块中有未限制更改的repo，SourceTree甚至会发出警告

单个存储库是可笑的。这意味着，每当有人想下载一个项目时，他们就必须全部下载

分支将变得过于复杂，无法修复适用于所有相关分支的错误

我当前项目的结构是：

项目回购（针对我个人从事的项目）
-项目基础回购（用于团队成员之间的共享代码）
--实用程序repo（用于在任何项目中都可重用的代码）

，它们使在应用程序之间管理相关代码变得简单

我们有一套类似的应用程序，最初管理起来非常痛苦，但一旦你运行了定制的CoCoapod，你就再也不会回头了。你应该查阅一本关于管理自己的CoCoapod的入门指南

它是免费的，功能强大，你会想为什么你从来没有使用过它们