首先，我要说的是，这个问题可能不适合SoftwareEngineering.SE，即使它类似于“白板”问题。这个问题必须与Git专门做，所以我想我会在这里问SO。这更像是“我该怎么做”或“我需要关注什么”的问题...我还需要先问这个问题，以便我不会完全破坏我的一个或多个Git存储库
无论如何，我有一个Git存储库，用于我目前正在构建的应用程序。此应用程序包含多个子模块，每个子模块用于应用程序所依赖的每个库。现在，我的一些子模块彼此依赖。例如，我在某些子模块中有一些不同的实现，这取决于单独子模块中的某些特定接口。
我正在考虑让 interface 库成为每个实现库的子模块......好吧，为了这个问题，它不一定是接口。我们只是说有涉及的库有自己的子模块 。现在问题......
如果将来我需要在新应用程序中支持两个不同的实现，那么当我将实现作为子模块包含在应用程序中时会发生什么？特别是......如果常见的子模块更新了......一个实现需要V1.0而另一个实现需要V2.0？是否存在某种冲突？
P.S。我真正试图摆脱这个问题...是一种方法让我的子模块每个都有一个引用＃（对于它们所依赖的库）它们需要的顺序编译...如果这不是正确的方法，那么我愿意接受替代方案。
答案 0 :(得分：0)
是一种方法让我的每个子模块都引用某个提交＃（对于他们所依赖的库），以便编译它们所需的
理想情况下，这些子模块应该有自己的子模块 子模块（I detailed here）的本质是已检出存储库的固定SHA1引用。
子模块A依赖于公共仓库C，版本1和子模块B的事实取决于公共C，版本2仅意味着A和B有C具有子模块，但引用了两个不同版本的C。
然而：
我想我必须坚持使用子模块，直到这个项目完成。如果我要保留子模块的子模块，我真的不认为这会起作用。 我的解决方案中不能有多个项目实例...所以项目不能包含他们自己需要的“个人”版本的依赖项 ..
在这种情况下，您需要有一个扁平的子模块组织 这意味着：即使这些子模块都有自己的子模块，你也可以不递归地克隆它们。您只能克隆父仓库的子模块（此处：A，B和公共C，主项目父仓库的所有直接子模块）
git submodule update --init
那将检查这些子模块（没有初始化/检查这些子模块的子模块）
你最终得到一个能够编译C的项目，然后是B和A，然后自己（假设A和B使用相同版本的C）。