使用常见的嵌套子模块组织Git存储库

我是Git子模块的忠实粉丝。我希望能够跟踪依赖关系及其版本，以便您可以回滚到项目的先前版本，并具有相应版本的依赖关系，以安全，干净地进行构建。此外，将我们的库作为开放源代码项目发布更容易，因为库的历史记录与依赖于它们的应用程序的历史记录是分开的（并且不会公开）。

我正在为工作中的多个项目设置工作流程，我想知道如果我们采用这种方法有点极端，而不是拥有一个整体项目会怎么样。我很快意识到，在真正使用子模块时，可能存在蠕虫病毒。

假设有一对应用程序：studio和player，以及依赖库core，graph和network，其中依赖关系如下：

• core 是独立的
• graph取决于core（的子模块./libs/core）
• network依赖于core（的子模块./libs/core）
• studio取决于graph和network（位于./libs/graph和的子模块./libs/network）
• player取决于graph和network（位于./libs/graph和的子模块./libs/network）

假设我们正在使用CMake，并且每个项目都有单元测试和所有工作。每个项目（包括studio和player）都必须能够独立编译以执行代码指标，单元测试等。

事情是，递归的git submodule fetch，然后您将获得以下目录结构：

studio/
studio/libs/                    (sub-module depth: 1)
studio/libs/graph/
studio/libs/graph/libs/         (sub-module depth: 2)
studio/libs/graph/libs/core/
studio/libs/network/
studio/libs/network/libs/       (sub-module depth: 2)
studio/libs/network/libs/core/

注意core在studio项目中克隆了两次。除了浪费磁盘空间之外，我还有一个构建系统问题，因为我要构建core两次，并且有可能获得的两个不同版本core。

题

如何组织子模块，以便获得版本化的依赖关系和独立的构建，而无需获取公共嵌套子模块的多个副本？

可能的解决方案

如果库依赖关系只是一个建议（例如，以“已知可与版本X一起使用”或“仅正式支持版本X”的方式），并且潜在的依赖应用程序或库负责使用其喜欢的任何版本进行构建，则我可以想象以下情形：

• 让构建系统知道graph并network告诉他们在哪里core（例如，通过编译器包含路径）。定义两个构建目标：“独立”和“依赖”，其中“独立”基于“依赖”，并添加包含路径以指向本地core子模块。
• 引入额外的依赖性：studio上core。然后，studio建立core，设置包括它自己的拷贝路径core子模块，然后建立graph与network在“依赖”模式。

生成的文件夹结构如下所示：

studio/
studio/libs/                    (sub-module depth: 1)
studio/libs/core/
studio/libs/graph/
studio/libs/graph/libs/         (empty folder, sub-modules not fetched)
studio/libs/network/
studio/libs/network/libs/       (empty folder, sub-modules not fetched)

但是，这需要一些构建系统的技巧（我很确信这可以使用CMake来完成）以及版本更新方面的一些手动工作（更新graph可能还需要更新core并network获得core所有项目中的兼容版本） 。

有什么想法吗？

我参加这个聚会已经很晚了，但是您的问题似乎仍然没有完整的答案，这在google上很受欢迎。

我在C ++ / CMake / Git / Submodules上有完全相同的问题，而在MATLAB / Git / Submodules上也有类似的问题，这由于未编译MATLAB而变得有些奇怪。我最近看了这段视频，似乎提出了“解决方案”。我不喜欢该解决方案，因为它本质上意味着丢弃子模块，但是确实消除了问题。就像@errordeveloper建议一样。每个项目都没有子模块。要构建项目，请创建一个超级项目来构建它，并将其作为其依赖项的同级对象。

因此，您的开发项目graph可能如下所示：

buildgraph/graph
buildgraph/core

然后您的Studio项目可能是：

buildstudio/studio
buildstudio/graph
buildstudio/network
buildstudio/core

超级项目只是一个主CMakeLists.txt模块和一堆子模块。但是，这些项目本身都没有任何子模块。

我看到的这种方法的唯一成本就是琐碎的“超级项目”的泛滥，这些“超级项目”仅用于构建您的真实项目。而且，如果有人掌握了您的一个项目，那么也很难找到不依赖超级项目的简单方法，即它的依赖性是什么。例如，这可能会使它在Github上显得非常丑陋。

我想当您将两者graph和network子模块集成到一起时studio，core在的历史记录中，给定的时间始终必须具有相同的版本studio。我会将studio/libs/core子模块简化为studio/libs/{graph,network}/libs。

更新：

我使用您声明的依赖项创建了多个存储库：

./core      <--- (v2)
./graph
./graph/libs
./graph/libs/core  <--- (v2)
./graph/.gitmodules
./network
./network/libs
./network/libs/core  <--- (v1)
./network/.gitmodules
./studio
./studio/libs
./studio/libs/graph
./studio/libs/graph/libs
./studio/libs/graph/libs/core <--- (v1)
./studio/libs/graph/.gitmodules
./studio/libs/network
./studio/libs/network/libs
./studio/libs/network/libs/core  <--- (v1)
./studio/libs/network/.gitmodules
./studio/studio
./studio/.gitmodules

v1和v2是的两个不同版本core。 graph处理版本2，但network需要做一些工作，并停留在版本1中。在中studio，两个的本地嵌入式版本core都指向v1，以便具有有效的程序。现在，除了构建角度以外，所有子模块都可以正常工作。

我现在可以删除以下目录：

./studio/libs/network/libs/core

并将其替换为符号链接：

./studio/libs/network/libs/core@ -> ../../graph/libs/core/

我在本地提交此更改，并失去了具有两个单独的coreinside 版本的能力studio，但我只构建了core一次。准备升级到时v2，我可以执行以下操作：

 git submodule update # (--rebase ?)

...在studio / libs / network内部。

我将其扁平化，以使子模块深度只有一个，并具有一个存储库，该存储库将所有模块作为子模块保存，除了README和构建脚本外没有其他内容。每个链接其依赖关系的软件包都有一个单独的构建脚本。否则，您可以有一个单独的软件包回购。

我不会使用子模块。

这很诱人，与svn-externals一样。但是，您可以确定所链接的所有这些项目仍在一年之内吗？五分之类的呢？

因此，我只是将所有必需的依赖项复制到我的项目中。这意味着只要我的仓库有效，我就可以签出确切的状态。

基本上，我的文件夹结构如下：

myproject/... [sources etc]
ext/ [third-party dependencies]


e.g. ext/boost, ext/cppunit

尽管从磁盘空间的角度来看这不是很好，但是我很保证我可以检查出所记录的每个状态，只要存储库的可用性更高。

此外，还有描述了一堆关于子模块的问题在这里

在这里面临完全相同的问题。一个解决方案可能是有一些回购libs，将举行core，network，graph为子模块，只是CMakeLists会告诉每个库在哪里可以找到它的依赖性。现在，每个应用程序都将libs作为子模块，并且仅使用必要的库。

每个库的测试可以通过两种方式设置：

• 将core_testing，graph_testing，network_testing作为单独的应用程序
• 将测试的库部署到测试服务器，并在使用cmake运行测试时找到它们