【发布时间】：2017-06-16 09:16:32
【问题描述】：
我有一个包含多个 Git 子模块的大项目。一个主项目使用不同库的集合，一些库本身使用库。所有库都可以独立使用，因此它们都需要一个包含测试基础架构（VUnit 和 UVVM）的子模块。
Git 子模块树如下所示：
ProjectA
o- libA
o- UVVM
o- VUnit
o- libB
o- UVVM
o- VUnit
o- libC
o- libA
o- UVVM
o- VUnit
o- UVVM
o- VUnit
o- libD
o- UVVM
o- VUnit
o- UVVM
o- VUnit
我对 Git 的内部数据库和链接结构有所了解。因此，子模块的 BLOB 存储在主存储库的 .git 目录中名为 modules 的目录中。它们通常具有与子模块目录名称相同的符号名称。
子模块使用包含相对路径的.git 文件指向其数据库主目录。作为回报，子模块数据库的配置文件指向子模块的工作树。
所以有可能所有的 UVVM 子模块都指向同一个数据库，但是一个数据库怎么可能指向多个工作树呢？
我发现 Git 扩展可以与多个工作目录一起使用，但它是否也可以与像我一样的子模块一起使用？
我也愿意接受其他建议。
编辑 1：
这是.git目录中生成的内部结构。它一遍又一遍地为 UVVM 和 VUnit 的每个子模块创建完整的对象存储。
.git/
modules/
libA/
modules/
UVVM/
VUnit/
libB/
modules/
UVVM/
VUnit/
libC/
modules/
libA/
modules/
UVVM/
VUnit/
UVVM/
VUnit/
libD/
modules/
UVVM/
VUnit/
UVVM/
VUnit/
服务器上的内存占用非常低，因为所有子模块都指向同一个存储库。但是客户端的内存占用非常高。
【问题讨论】：
-
在文件系统级别使用硬链接或重复数据删除就足够了吗？
-
我不确定 Git 是如何进行文件操作的。例如。使用 SVN，它确实删除和创建操作，而不是就地内容替换。这样的操作会破坏硬链接。我还在为新用户寻找与
git clone一起使用的解决方案。我们在一个由 8 名开发人员组成的小组中工作，其中一些在 Windows 上，一些在 Linux 上。 （顺便说一句。Windows 确实支持 NTFS 中的硬链接 :)） -
我认为明确说明您正在寻找可以帮助存储库用户的解决方案会有所帮助，我假设您只是在寻找服务器解决方案（在适当的文件系统上的裸存储库将适当）。据我所知，git 使用很少更改的大 blob 文件。但是，您仍然有已检出文件的重复项。经常重新创建硬链接可能是必要的，也许这不是要走的路。
-
我正在寻找用户方面的解决方案。服务器端没有重复，因为“重复”的代码在子模块中。
标签： git git-submodules memory-footprint