Git 子模块跟踪分支有效

Question

我想在我的公司内推广 monorepo 的想法。
我打算这样使用它们：

我有一个 'parent' 回购 为我们堆栈的每个组件保存一个子模块，从而维护全局版本控制整个堆栈（我们可以简单地检查给定分支上的每个组件）

这听起来很完美，因为我们仍然可以从开箱即用的任何 CI 服务中受益（我们是否仍然推动独立的 git 回购，子模块）。

这种方法唯一（可怕的）弱点是，如果执行

git submodule update --remote

使用以下配置：

[submodule "commonLib"]
   path = commonLib
   url = git@github.com:org/commonLib.git
   branch = MY_BRANCH

每个子模块在正确的提交时有效地检出。

但是：他们都是独立的头

为什么没有办法有效地使用 gitsumodule with branch. 即：更新时，有效地签出分支而不是该分支指向的提交？是出于技术原因还是只是尚未在 git 中实施？

谢谢

Answer 1

部分答案是 git 子模块旨在允许 consistent/coherent 查看一组多个存储库。实现这一目标的唯一方法是将每个子模块锁定在特定版本，父仓库跟踪所有子模块的所有版本，从而使整个项目看起来像一个 monorepo。

在这样的项目上下文中工作时，仅在分支级别指定某个子模块没有多大意义，因为这可能会选择与项目其余部分不一致的版本。

答案的另一部分不是特定于 git 子模块，而是特定于任何 git 回购：当提取特定版本时，回购将处于分离头状态。对分支识别的支持不多，因为在 git 中，分支的含义和重要性与在其他版本控制系统中的不同，有关详细信息，请参阅这个优秀的答案：.

我发现有 2 种可能的方法可以降低在更新时选择正确的分支时出现人为错误的风险：

在所有存储库和 labels/tags（最好由 CI/CD 系统生成）中使用一致的分支名称，这些分支名称在其标识符中编码。一开始是一个相当困难的销售，每个拥有组件的团队都希望获得完全的决策权，但它可以变得更好，if/when 团队最终明白他们实际上需要对齐才能一起制作一个连贯的产品。
提供项目级自动化包装器来操作存储库，这将从父存储库中提取正确的分支信息（同时还执行完整性检查 and/or 相关操作以维护开发人员的工作区和项目的一致性）。

Git submodule track branch effectivly