Git嵌套的子模块和依赖关系

问题描述

假设我有四个名为核心， A ， B ，超级的项目。依赖关系树是这样的：

  Super --->核心
 |  - > A  - >核心
 |  - > B  - >核心
  

我希望每个项目都是独立的，也就是说，我希望能够检查-out和自己编译每个项目（当然每个项目都有它的依赖关系）。

我想过将每个项目映射到一个存储库，然后引用子模块的依赖关系，但是我发现这种方法存在以下问题：

1. 在检查 Super 及其所有依赖关系时，我最终会收到三份 Core 。
>

2. 由于子模块是完全独立的，因此这三个副本中的每一个都可能指向 Core 的不同修订版本，这会变得很糟糕。

所以...我错过了什么吗？我误解了git submodules还是误用了它们？有没有其他的解决方案来解决这个问题（除了求助于二进制依赖）？

解决方案

您刚刚发现缺少重写的依赖关系使用Git子模块：

如果Super取决于Core，则Core的依赖关系应该覆盖A和B与Core关联的关系。

要模拟的唯一方法是按照您的方式创建您的超级项目，

和以删除A和B的子模块核心

（意思是超级现在取决于A'和B'，A'是没有核心的A，B是没有核心的B）

Let's say I have four projects named Core, A, B, Super. The dependency tree is like this:

Super ---> Core
       |-> A -> Core
       |-> B -> Core

I want each project to be stand-alone, that is, I want to be able to check-out and compile each project on its own (each with its dependencies of course).

I thought about mapping each project to a repository and then referring dependencies with submodules, but I see the following issues with that approach:

1. When checking out Super with all its dependencies, I'd end up with three copies of Core.
2. Since submodules are fully independent, each of these three copies could be pointing to different revisions of Core and that would be a mess.

So... Am I missing something? Did I misunderstand git submodules or misusing them? Is there any other solution to this problem (other than resorting to binary dependencies)?

解决方案

You just discovered the lack of overridden dependencies with Git submodules:

If Super depends on Core, its dependency of Core should "override" the ones A and B have with Core.

The only way to emulate that would be to create your Super project the way you did,
and to remove the sub-module Core of A and B.
(meaning Super depends now on A' and B', A' being A without Core, B' being B without Core)

这篇关于Git嵌套的子模块和依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！