我有一些工作树有一些依赖。 AFAIK，git子模块将强制执行以下操作：
- 使用它（主）在每个工作树的子目录中拥有每个工作树（slave）的副本
- 主存储库复制来自从属的所有信息
我不介意回购更大，但拥有副本对我来说是非常不可接受的。它会迫使我重新组织所有项目，以便将副本链接起来。此外，编辑错误的文件很容易发生，从而导致混淆。
我有另一个想法：
- 每个主服务器都存储其所有从服务器的列表。
- 主站中不需要其他信息。
- 每次在master中提交时，“快照提交“在奴隶中得到了创造。
- “snapshot-commit”是工作树当前状态的快照，它忽略了索引的当前状态（我在丢弃一些未经修改的更改之前已经使用了“snapshot-commits”）。
- “snapshot-commits”收集在一个分支中，该分支的名称来自主人的名字。提交消息包含主提交的哈希。 （恕我直言，这比成千上万的标签充斥更好。）
- 结账工作照常工作，除非需要递归奴隶。
我能看到的唯一问题如下：
- 从站中的提交将累积，即使主提交不再存在，也永远不会被删除。
- 主服务器中的提交不是自包含的，您可以删除主服务器中引用的提交。但我认为不可能偶然发生，所以我可以忍受它。
- 我无法想象，其他git命令如何支持这一点。但同样，我可以忍受它。
我问的是有人已经实现了它（或者这是一个坏主意）。
我认为这是一个坏主意，因为它很奇怪，它会让你离开许多事情的支持路径。
首先澄清一下：当使用子模块时，'master'（引用）repo不会明显变大。它仅存储存储库引用（可能是URL）和提交ID。但这似乎不是这里的关键点。
在处理这样的问题时，您可以使用三条基本路径：
将所有内容放在一个存储库中。你有10次说服自己真的需要将事情分开吗？请记住，您可以从一个仓库开始，然后再拆分。还要记住，git merge实际上是有效的，因此开发人员争用并不是一个问题。
使用一些外部包管理系统。 Git不是，也不是假装是包经理。您正在使用的平台有一个包管理器支持更复杂的依赖情况。 Maven，rubygems，npm，nuget ......有很多。
在子目录中使用“已安装”子模块。
基本上，在处理您自己的代码时，子模块应该是您的最后选择。它们非常适合处理第三方库，但最终会成为您自己代码的王室痛苦。除此之外，您还提出了一个复杂的解决方案，而且工作起来不会很有趣。
我认为这是一个坏主意，因为它很奇怪，它会让你离开许多事情的支持路径。
首先澄清一下：当使用子模块时，'master'（引用）repo不会明显变大。它仅存储存储库引用（可能是URL）和提交ID。但这似乎不是这里的关键点。
在处理这样的问题时，您可以使用三条基本路径：
将所有内容放在一个存储库中。你有10次说服自己真的需要将事情分开吗？请记住，您可以从一个仓库开始，然后再拆分。还要记住，git merge实际上是有效的，因此开发人员争用并不是一个问题。
使用一些外部包管理系统。 Git不是，也不是假装是包经理。您正在使用的平台有一个包管理器支持更复杂的依赖情况。 Maven，rubygems，npm，nuget ......有很多。
在子目录中使用“已安装”子模块。
基本上，在处理您自己的代码时，子模块应该是您的最后选择。它们非常适合处理第三方库，但最终会成为您自己代码的王室痛苦。除此之外，您还提出了一个复杂的解决方案，而且工作起来不会很有趣。
我不确定我是否关注您，因为父回购（您的“主”）仅存储对子模块的紧密SHA1的引用（在父回购中检出的子回购）。
父回购的大小根本不受影响。
该 子树合并策略 （通过git子树更好地管理）会增加父repo的大小，但是（子树合并）不是你所说的。
子模块的另一种替代方案是 git-slave（gits），这有点像你想要实现。