Git非常棒，但是如果你有相同存储库的多个实例，那么使用的大小就会开始累加。
鉴于我对内部的理解（我承认是有限的），在我看来，所有实例在概念上都应该能够共享实例数据库的一部分，即存放实际文件/增量的部分（即历史记录） ）。说明指向哪些文件，分支信息等的内容当然必须在每个实例级别上。
每个实例中的整个存储库（甚至是浅存储库）不仅看起来很浪费，而且在受约束的系统上也存在问题。
git中有一些当前机制可以做到这一点吗？如果没有，听起来好像可以吗？也许通过结点/符号链接共享.git的子目录？
答案 0 :(得分：3)
是的，事实上，如果其中一个存储库是从另一个存储库克隆的，那么这是（部分）默认值。
<强>
--local的-l当要克隆的存储库位于本地计算机上时，此标志会绕过正常的＆＃34; Git aware＆＃34;传输机制并通过制作HEAD的副本以及对象和refs目录下的所有内容来克隆存储库。.git/objects/目录下的文件是硬链接的，以便在可能的情况下节省空间。如果将存储库指定为本地路径（例如，/ path / to / repo），则这是默认值，而--local本质上是无操作。如果将存储库指定为URL，则忽略此标志（并且我们从不使用本地优化）。指定--no-local将在给出/ path / to / repo时覆盖默认值，而是使用常规Git传输。
（强调已添加）
这意味着在支持硬链接的系统上（Linux和Unix系统，包括Mac OS;理论上是Windows，但我不知道Git是否支持它），Git对象文件将只存储在光盘上一次。
但是，我发现在git fetch或git push上仍然存在这种情况。可能只有第一次制作克隆时存在的文件才会以这种方式共享。如果您通过遥控器在存储库之间进行更改，情况确实如此。
另一个选项是Git worktrees。这允许您在不同目录中同时检出存储库的多个分支。在这种情况下，光盘上只有一个版本的存储库，所以即使你更新它也总是共享。
但是，这不允许您在不同的工作树中检出相同的分支（没有--force选项，这仍然是实验性的），这可能是一个优势或缺点取决于您的使用案例。它也不会让你有一个只读存储库和一个可写的克隆，如果你在同一台计算机上有多个用户，这可能会很有用。
根据您的使用情况，任一选项（或两者一起）可能就是您想要的。
答案 1 :(得分：0)
管理多个共享同一存储库的工作树大约两年前实现（Git 2.6左右）。命令为git worktree。