ios - 两个 iOS 应用程序的 Git 存储库结构，其中一个应用程序从另一个应用程序大量派生

Question

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

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

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

这里还有一些我考虑过的事情:

子模块

我以前使用过子模块，但不是专家。我的理解是包含子模块的“ super ”存储库还存储对子模块特定提交的引用。这部分涉及确保多个存储库(即应用程序 + 库)将同步移动，尽管我猜仍然存在需要从子模块手动提取更改的问题。此外，如果开发人员碰巧忘记推送其更改并且它被 super 存储库引用，则子模块提交无法 pull 出的问题。

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

单一存储库

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

单一存储库的一个很好的方面是一切都在同步进行 - 没有人需要担心保持多个存储库版本匹配。如果使用 XCode 工作区，甚至可以跨两个应用程序进行重构。

分枝

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

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

Answer 1

使用子模块。您不需要成为专家，因为它们非常易于使用。尤其是与 SourceTree 之类的 GUI 结合使用时。我和你有完全相同的情况，这就是我所做的。如果您尝试提交在子模块中有未提交更改的 repo，SourceTree 甚至会警告您。

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

对适用于所有相关分支的错误修复进行分支将变得过于复杂。

我当前项目的结构是:

项目 repo (对于我个人从事的项目)
-项目基础 repo (用于团队成员之间的共享代码)
--Utilities repo(用于在任何项目中可重用的代码)