Question

我想在公司内推广monorepo的想法我打算用这种方式使用它们：

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

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

这种方法唯一（可怕）的弱点是，如果做了一个

git submodule update --remote

使用以下配置：

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

每个子模块在正确的提交时都会被有效地检查。

但是：他们都处于分离头

为什么没有办法有效地使用带分支的gitsumodule。即：更新时，有效地检查分支，而不是该分支指向的提交？是出于技术原因还是尚未在git中实现？

由于

Answer 1

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

在这样的项目环境中工作时，在分支级别指定某个子模块并不是很有意义，因为这可能会选择一个与其他部分不一致的版本。项目。

答案的另一部分并非特定于git子模块，而是针对任何git repo：当拉动特定版本时，repo将处于分离头状态。由于git分支不具备与其他版本控制系统相同的含义和重要性，因此对分支识别的支持不多，请参阅此优秀答案以获取详细信息：https://stackoverflow.com/a/3162929/4495081。

在更新中选择正确的分支时，我看到了两种降低人为错误风险的方法：

在所有存储库和标签/标签（最好由CI / CD系统生成）中使用一致的分支名称，这些名称/标签的分支名称在其标识符中编码。一开始就很难卖出，每个拥有组件的团队都希望拥有完整的决策权，但是如果/当团队最终明白他们确实需要协调一致来制作一个连贯的产品时，它会变得更好。
提供项目级自动化包装器以对存储库进行操作，这将从父存储库中提取适当的分支信息（同时还执行健全性检查和/或相关操作以维护开发人员的工作空间和项目的一致性。）

Git子模块轨道分支有效

1 个答案: