Git子模块替代品？

Question

我有几个工作树有一些依赖。据我所知，git submodule 将强制执行以下内容:

• 在每个使用它的工作树(主)的子目录中拥有每个工作树(从属)的副本
• 主存储库复制从属存储库的所有信息

我不介意 repo 协议(protocol)变大，但拥有副本对我来说是完全不能接受的。这将迫使我重新组织所有项目，以便副本可以链接。此外，编辑错误的文件很容易导致困惑。

我有另一个想法:

• 每个 master 存储其所有 slave 的列表。
• 不需要母版中的其他信息。
• 每次在 master 中提交时，都会在 slave 中创建一个“snapshot-commit”。
• “snapshot-commit”是工作树当前状态的快照，它忽略了索引的当前状态(我在丢弃一些未提交的更改之前已经使用了“snapshot-commits”)。<
• “snapshot-commits”被收集在一个分支中，该分支的名称来源于主人的名字。提交消息包含主提交的哈希值。 (恕我直言，这比成千上万个标签泛滥要好。)
• 除非需要递归到从站，否则 checkout 工作照常进行。

我能看到的唯一问题如下:

• slave 中的提交会累积，即使 master 提交不再存在也不会被删除。
• master 中的提交不是自包含的，您可以删除 master 中引用的提交。但我认为这不可能是偶然发生的，所以我可以忍受。
• 我无法想象其他 git 命令如何支持这一点。但同样，我可以忍受。

我想问是否有人已经实现了它(或者这是否是个坏主意)。

Answer 1

我认为这是个坏主意，因为它很奇怪，而且会让您在很多事情上偏离受支持的路径。

首先澄清一下:使用子模块时，“主”(引用)存储库不会明显变大。它只存储一个存储库引用(可能是 URL)和一个提交 ID。但这似乎并不是这里的症结所在。

当处理这样的问题时，基本上有 3 条路径可供选择:

1. 将所有内容放在一个存储库中。你有没有说服自己 10 次你真的需要把事情分开？请记住，您可以从一个存储库开始，然后再拆分。还要记住 git merges 确实有效，所以开发人员争用并不是什么大问题。

2. 使用一些外部包管理系统。 Git 不是，也不会假装是包管理器。您正在使用的平台有一个支持更复杂的依赖情况的包管理器的可能性很大。 Maven、rubygems、npm、nuget……有很多。

3. 在子目录中使用子模块“mounted”。

基本上，子模块应该是您处理自己的代码时的最后选择。它们非常适合与第三方库打交道，但最终却成为您自己代码的一大难题。再加上您提出的复杂解决方案，使用起来就不会很有趣。