Git Submodules在嵌入式项目中的优缺点及使用决策咨询

我们在嵌入式项目的可复用代码管理上，对是否使用Git Submodules存在分歧：

• 部分开发者认为Submodules会让工作流程变复杂，Linux内核这类大型项目采用单一扁平仓库且未使用Submodules，主张效仿这种模式，用一个「主项目」作为所有独立产品的基础，而非让各产品仅引入所需Submodules。
• 另一部分开发者则认为单一仓库会降低模块化程度，增加跨项目复用难度，且难以维护。

这类讨论已多次陷入循环，我需要深入了解Git Submodules的设计用途、优缺点，以便做出合理决策。

目前我们将「核心模块」（如音频处理库、无线库等）、硬件平台BSP、各类硬件通用驱动、第三方库（如厂商HAL）分别放在独立仓库中版本控制，这些组件均会跨多个独立项目复用。其中核心模块开发进度快、风险高，破坏性变更较为常见。

简言之，Submodules主要用于以下场景：

• 库或「可复用模块」
• BSP
• 驱动
• 第三方库（如厂商HAL）

Git Submodules的核心设计目标是在一个Git仓库中引用另一个独立Git仓库的特定版本，本质是实现仓库间的版本依赖管理，主要适用于以下场景：

1. 复用独立维护的组件：当某个模块需要被多个项目共享，且该模块有独立的开发节奏、版本周期时，Submodules可以让每个项目锁定该模块的特定版本，避免版本混乱。
2. 整合第三方代码：对于不需要修改的第三方库（如厂商HAL），Submodules可以直接引入其官方仓库的指定版本，无需手动复制代码，便于后续更新。
3. 分离高风险模块：将开发节奏快、破坏性变更多的模块独立为子仓库，主项目可以选择稳定版本引入，避免主项目被频繁的不稳定变更影响。

优点 #

• 保持模块独立性：每个子模块有独立的仓库、提交历史和版本管理，模块维护者可以专注于自身开发，不受主项目节奏限制。
• 精确版本控制：主项目可以精准锁定子模块的某个commit/tag，确保所有开发者使用的子模块版本一致，避免因版本差异导致的编译或运行问题。
• 降低主仓库体积：无需将所有复用代码复制到主仓库，减少主仓库的提交历史复杂度和存储体积。
• 便于第三方库管理：直接引入第三方仓库的指定版本，更新时只需同步子模块版本，无需手动替换代码。

缺点 #

• 工作流程复杂：使用Submodules需要掌握额外的命令（如git submodule init、git submodule update、git submodule sync等），新手学习成本高，且容易出现子模块版本同步错误（如忘记更新子模块、提交主仓库时未同步子模块的最新commit）。
• 协同开发难度高：如果主项目和子模块同时需要修改，需要分别在两个仓库提交，再同步主仓库的子模块引用，流程繁琐；当多个项目依赖同一个子模块时，子模块的破坏性变更可能需要同时更新所有依赖项目，协调成本高。
• CI/CD配置复杂：持续集成时需要额外配置拉取子模块的步骤，若子仓库有权限限制，还需处理权限问题，增加CI/CD的复杂度。
• 单一仓库的对比优势：像Linux内核这样的单一扁平仓库，代码共享更直接，无需处理跨仓库的依赖问题，协同开发时可以在同一个仓库提交所有修改，流程更简洁，适合所有模块高度耦合、开发节奏一致的项目。

结合当前多项目复用独立模块、核心模块变更频繁且有破坏性的场景，可以从以下角度权衡：

1. 若选择继续使用Submodules：

   • 制定明确的使用规范：要求子模块必须使用tag锁定版本，禁止直接引用分支；明确子模块更新、提交的流程，避免版本混乱。
   • 分类管理子模块：对于第三方库、稳定的BSP/驱动，锁定稳定版本；对于变更频繁的核心模块，建立「稳定分支」，主项目仅引用稳定分支的tag，允许开发者在本地切换到开发分支测试。
   • 简化CI/CD流程：在CI脚本中自动添加拉取子模块的步骤，比如使用git clone --recurse-submodules命令，减少手动操作。

2. 若选择单一扁平仓库：

   • 重构模块结构：将所有复用模块整合到主仓库，建立清晰的目录结构（如/core、/bsp、/drivers），明确各模块边界。
   • 制定严格的分支策略：用开发分支、稳定分支分离，核心模块的破坏性变更需在开发分支完成测试后再合并到稳定分支，避免影响所有产品项目。
   • 解决跨项目复用问题：通过脚本提取指定模块到独立产品项目，或使用Git的sparse-checkout功能，让各产品仅拉取所需模块代码，减少仓库体积。

内容的提问来源于stack exchange，提问作者DarkFranX