如果我已经在本地拥有相同的文件，而不是从远程存储库中下载大型文件目录，有没有办法用文件“预加载”我的本地存储库？我已经在远程的本地具有相同的文件，它们不在本地仓库中。
这是我的情况：
我有一个远程网站，有一个很大（很多演出）的资源目录（图像，PDF，swfs，flvs）。我已经为这个远程站点设置了一个git存储库，我已经在本地克隆了它，使用.gitignore文件来排除大资源目录被包含在repo中。
我现在想把远程仓库的大资源目录作为一部分，但这会大大增加仓库的大小，当我进行下一次本地拉动时，我需要进行相当长的等待/下载。所以我基本上希望有一种方法可以告诉git“我会要求你拉回那个突然大得多的回购，但我已经把大部分东西都变得如此之大”？或者这可能是另一种方式，我首先将文件添加到我的本地仓库然后以某种方式存储库解决它们有相同的文件并且不需要传输？
当新的开发人员进入一个大型项目并且大部分可以在DVD上提供而不是他们必须克隆/下载巨大的回购时，这也会派上用场。
我建议你要特别注意养成习惯，不要在你的git中添加千兆字节的二进制文件，而不要考虑像git-annex这样的选项。
现在。仅仅在本地使用文件本身并不足以让Git使用它们。您可以使用git hash-object手动将大二进制文件添加到网络鸿沟两侧的Git对象数据库中，并在另一侧创建包含完全相同文件的提交，但是在推送/获取此类提交时Git不够智能弄清楚那些物体已经存在于另一边;因为不存在需要传输的提交，所以大blob将包含在通过线路传输的结果包文件中。为避免这种情况，您必须手动复制所有提交和树对象，但省略大blob。可行，但可能比它的价值更麻烦。
更现实的方法是对网络传输进行一次攻击，并对未来的传输采取明智行动。您可以拥有一个人们可以克隆的本地镜像。如果这还不够快，那就表明你的git太大了。
您还可以使用git clone --reference <ref> <url>克隆git，其中<ref>是包含您正在克隆的git的本地目录。这将重用参考git中的所有对象，使克隆速度极快。但是，如git clone manpage中所述，新克隆将直接引用旧克隆中的对象，因此如果删除旧克隆，则会遇到麻烦。要实际复制对象，您可以在克隆后运行git repack -a。
git clone --reference /some/old/clone http://example.com/some/git dirname
cd dirname
git repack -a
rm .git/objects/info/alternates
最后一个命令删除了引用git的链接，因此Git将来不会尝试在那里查找对象。
要在例如上分发Git存储库DVD或类似的存储机制可以查看git bundle。参见例如How to git bundle a complete repo。
我只把git源代码，图片的所有部分，pdf，图像。 ..我会创建一个单独的存储服务器，在我的应用程序中，我链接到存储。
今天（2017年第四季度/ 2018年第一季度，OP问题发布4年后），克隆巨大Git回购的唯一Git相关方式将是（2017年2月）GVFS (Git Virtual File System)。
作为tweeted，270GB回购：
“Windows代码库有超过3.5M的文件。使用GVFS（Git虚拟文件系统），克隆现在需要几分钟而不是12个多小时。“
见github.com/Microsoft/GVFS。
GVFS基于Git fork：github.com/Microsoft/git。
并且基于规范为described here的协议。
目前尚未支持EGit，甚至普通的Git，但是这种机制的整合已经开始，Git 2.16（2018年第一季度），以及窄/部分克隆的实现，其中物体行走机械已经教会了一种方法来告诉它从枚举中“过滤”一些对象。
这是围绕部分克隆讨论的结果，documented here（2017年11月），尽管问题是highlighted back in May 2013：
使用大型存储库时，必须获取用户感兴趣的历史区域中的所有对象是浪费的。 在两种情况下尤其如此：
- 使用稀疏结账：不太可能需要用户正在查看的目录之外的对象。之后，如果需要的话，用户应该能够获取该目录之外的对象（例如，如果稀疏结账扩展）。当与确定要自动使用的稀疏结账模式的虚拟文件系统（https://blogs.msdn.microsoft.com/devops/2017/02/03/announcing-gvfs-git-virtual-file-system/）结合使用时，这尤其有用。
- 存储库包含大型二进制文件：为了构建最新版本的代码，不需要历史版本的大文件。 使用浅层克隆失去了使用“
git log”来理解项目在开发过程中的历史的能力。 使用Git LFS需要提前预测此问题并确定要提前卸载到LFS的文件。 在Git中原生支持省略大blob避免了这种困境。Microsoft和Google都在内部使用补丁来支持部分克隆并发布了补丁。此问题跟踪将功能合并到Git上游。
结果是：
请参阅commit f4371a8，commit 4875c97（2017年12月5日）和commit 9535ce7，commit caf3827，commit 25ec7bc，commit c3a9ad3，commit 314f354，commit 578d81d（2017年11月21日）。
请参阅Jeff Hostetler (jeffhostetler)撰写的commit 1dde5fa（2017年12月5日）。
（Christian Couder (chriscool)于2017年12月27日在Junio C Hamano -- gitster --合并）
commit 61061ab /
rev-list：添加列表对象过滤支持教转法列表以使用
pack-objects接口提供的过滤从结果中省略不需要的对象。将来，我们将介绍一种“部分克隆”机制，其中从远程获得的repo中的对象可以引用可以在需要时从该远程动态获取的丢失对象。 这种“部分克隆”机制将有一种方法，有时很慢，可以确定缺失的链接是否是该机制预期产生的链接之一。
该补丁引入了缺失对象的处理，以帮助调试和开发“部分克隆”机制，并且一旦实现该机制，高级用户就可以执行缺少对象感知的操作，而不会产生检查是否缺少链接的成本是期待。