Git子模块替代？

Question

我有一些工作树有一些依赖.AFAIK,git子模块将强制执行以下操作:

我不介意回购更大,但拥有副本对我来说是非常不可接受的.它会迫使我重新组织所有项目,以便将副本链接起来.此外,编辑错误的文件很容易发生,从而导致混淆.

我有另一个想法:

每个主服务器都存储其所有从服务器的列表.
主人不需要其他信息.
每次在master中提交时,都会创建slave中的" snapshot-commit ".
"snapshot-commit"是工作树当前状态的快照,它忽略了索引的当前状态(我在丢弃一些未经修改的更改之前已经使用了"snapshot-commits").
"snapshot-commits"收集在一个分支中,该分支的名称来自主人的名字.提交消息包含主提交的哈希.(恕我直言,这比成千上万的标签泛滥更好.)
结帐工作照常,除非需要递归奴隶.

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

我问是否有人已经实施了(或者这是一个坏主意).

Answer 1

我认为这是一个坏主意,因为它很奇怪,它会让你离开许多事情的支持路径.

首先澄清一下:当使用子模块时,'master'(引用)repo不会明显变大.它仅存储存储库引用(可能是URL)和提交ID.但这似乎不是这里的关键点.

处理这样的问题时,您可以使用三条基本路径:

将所有内容放在一个存储库中.你有10次说服自己真的需要把事情分开吗？请记住,您可以从一个仓库开始,然后再拆分.还要记住,git merge实际上是有效的,所以开发者争用并不是一个问题.
使用一些外部包管理系统.Git不是,也不是假装是包经理.您正在使用的平台有一个包管理器支持更复杂的依赖情况.Maven,rubygems,npm,nuget ......有很多.
在子目录中使用"已安装"子模块.

基本上,在处理您自己的代码时,子模块应该是您的最后选择.它们非常适合处理第三方库,但最终会成为您自己代码的王室痛苦.除此之外,您还提出了一个复杂的解决方案,工作起来并不是很有趣.

Answer 2

我不确定我是否在关注您，因为父存储库（您的“主”）仅存储对子模块的严格 SHA1 的引用（在父存储库中签出的子存储库）。
父存储库的大小根本不受影响。

子树合并策略（通过 git subtree 更好地管理）会增加父存储库的大小，但这（子树合并）不是您所讨论的。

子模块的另一个替代方案是git-slave (gits)，这有点像您想要实现的。