使用 git 子模块有哪些优点和缺点？

Question

问题

我们在工作中面临着关于在嵌入式项目中使用子模块来实现可重用代码的相互冲突的观点。

• 一些开发人员认为他们使工作流程变得复杂，并且像 Linux 内核这样的现有项目根本不使用它们，因为它是一个单一的、扁平的存储库，我们应该以他们为例。他们提出这个“主项目”应该成为我们所有独立产品的基础，而不是让所有产品只包含所需的子模块。
• 其他人提出，将所有内容版本化到单个存储库中会降低模块化性（使其他项目的可重用性变得复杂）并使其难以维护。

我不知道该怎么想，这不是我们第一次进行这样的讨论，感觉就像我们在兜圈子（历史重演）。

我需要更好地了解 git 子模块的预期用途、它们的优点和缺点，以便就我们应该做什么做出明智的决定。

我们当前使用的子模块

现在，我们正在自己的存储库中对“核心”（例如音频处理库、无线库等）进行版本控制。这些内核在许多独立项目中重复使用，在许多独立的硬件平台上运行。这些硬件平台 BSP 也在其自己的存储库中独立进行版本控制。各种硬件组件的通用驱动程序也是如此。所有这些组件都在独立项目中重用，其中一些组件（主要是“核心”）的开发进度非常快且风险很大；重大变化是这些的标准。

简而言之，我们使用子模块来：

• 库或“可重用模块”
• BSP
• 司机
• 第三方库，例如供应商 HAL

Answer 1

Git 子模块代表了一种以明确定义的方式组合多个存储库内容的方法。这是一种技术解决方案，一旦您决定在不同的存储库（或分支）中维护代码，您就可以使用它。 所以，

您要问的基本问题是：您想使用单个“monorepo”还是“polyrepo”设置？

这两个概念备受争议，每个概念都有自己的优点和缺点，我的建议是你仔细看看什么最适合你的情况。

有两个关键点

A
• monorepo

  使维护代码更改变得非常容易，否则这些代码将驻留在不同的位置（例如，您的应用程序使用驱动程序的新功能）。缺点是，单一存储库在技术上要求更高（存储库更大，建立高效的 CI 管道可能很棘手）。

• polyrepo

  设置（例如，使用子模块）使用起来更复杂（如开发人员所述）。将东西放在不同的地方意味着您需要一个好的解决方案来将来自不同来源的“匹配”代码组合在一起。然而，它在技术上要求不高，而且为每个组件设置 CI 也很简单。

“将匹配代码组合在一起的良好解决方案”是一件很难做到的事情，因为您需要显式控制依赖关系（例如，应用程序需要 libX rev 1.1 和 libY rev 2.2，但 libY rev 2.2 仅使用 lib X rev 进行了测试0.9）。使用单一存储库，您可以预先避免这个问题。