代码之家 › 专栏 › 技术社区 › Clement

Git子模块有效跟踪分支

monorepo git-submodules git

0

Clement · 技术社区 · 7 年前

我想在公司内部推广monorepo的理念。
我打算这样使用它们:

我有一个 '父级' 回购 为堆栈的每个组件保留一个子模块 ,从而维护整个堆栈的全局版本控制(我们可以简单地签出给定分支上的每个组件)

这听起来很完美,因为我们仍然可以从任何现成的CI服务中获益(我们仍然在推动独立的git repo,即子模块)。

这种方法唯一(可怕)的缺点是,如果

git submodule update --remote

使用以下配置:

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

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

但是: 他们都在超脱的头脑中

i、 e:更新时,有效签出分支而不是该分支所指的提交? 这是出于技术原因还是根本没有在git中实现?

谢谢

1 回复 | 直到 7 年前

1

2

Dan Cornilescu 7 年前

答案之一是git子模块的设计允许对一组多个存储库进行一致/连贯的查看。实现这一点的唯一方法是将每个子模块锁定在特定版本,父回购跟踪所有子模块的所有版本,从而使整个项目看起来像一个单回购。

在这样的项目环境中工作时,仅在分支级别指定某个子模块没有多大意义,因为这可能会导致出现与项目其余部分不一致的版本。

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

在所有存储库和标签/标签(理想情况下由CI/CD系统生成)中使用一致的分支名称,其标识符中编码了分支名称。一开始,销售相当困难,每个组件拥有团队都希望拥有完整的决策权,但如果/当团队最终了解到他们实际上需要协调一致才能共同生产出一致的产品时,销售会变得更好。
提供项目级自动化包装器以在存储库上操作,这将从父repo中提取适当的分支信息(同时还执行健全性检查和/或相关操作,以维护开发人员的工作空间和项目一致性)。