0

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

我有一个“父”仓库为我们堆栈的每个组件保存一个子模块，因此维护整个堆栈的全局版本控制（我们可以简单地检查给定分支上的每个组件）

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

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

git submodule update --remote

使用以下配置：

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

每个子模块都在正确的提交处有效地签出。

但是：他们都在超然的头脑中

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

谢谢

4

1 回答 1

2

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

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

答案的另一部分不是特定于 git 子模块，而是特定于任何 git repo：当提取特定版本时，repo 将处于分离的头部状态。由于在 git 中分支的含义和重要性与其他版本控制系统中的不同，因此对分支识别的支持并不多，有关详细信息，请参阅这个出色的答案：https ://stackoverflow.com/a/3162929/4495081 。

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

  • 在所有存储库和标签/标签（理想情况下由 CI/CD 系统生成）中使用一致的分支名称，其中分支名称编码在其标识符中。一开始是一个相当困难的销售，每个拥有组件的团队都希望拥有完整的决策权，但如果/当团队最终明白他们实际上需要协调一致来共同制作一个连贯的产品时，它会变得更好。

  • 提供项目级自动化包装器以对存储库进行操作，这将从父存储库中提取正确的分支信息（同时还执行完整性检查和/或相关操作以维护开发人员的工作空间和项目的一致性）。

于 2017-11-06T03:37:00.820 回答