【问题标题】:Git repository structure for two iOS apps where one app derives heavily from the other两个 iOS 应用程序的 Git 存储库结构,其中一个应用程序从另一个应用程序大量派生
【发布时间】:2013-06-16 18:51:14
【问题描述】:

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

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

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

以下是我考虑过的其他一些事情:

子模块

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

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

单一存储库

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

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

分支

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

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

【问题讨论】:

    标签: ios git version-control branching-and-merging


    【解决方案1】:

    Cocoapods,它们使管理应用程序之间的相关代码变得简单。

    我们有一套类似的应用程序基础,最初管理起来非常痛苦,但是一旦您运行自定义 cocoapods,您将永远不会回头。您应该查看 this 以获取有关管理您自己的 cocoapods 的入门指南。

    它是免费的,它很强大,你会想知道为什么你从来没有早点使用它们。

    【讨论】:

      【解决方案2】:

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

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

      分支会变得过于复杂,因为要修复适用于所有相关分支的错误。

      我当前项目的结构是:

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-05-29
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多