跟踪大型二进制文件时，git非常慢
我的项目是六个月大，git非常慢。 我们跟踪大约5 MB到50 MB的30个文件。 那些是二进制文件，我们把它们保持在git中。 我相信这些文件正在让git变慢。
有没有办法从存储库中杀死所有大于5MB的文件？ 我知道我会失去所有这些文件，这对我来说没问题。
理想情况下，我想要一个列出所有大文件（> 5MB）的命令。 我可以看到列表，然后我说好，继续删除这些文件，并使git更快。
我应该提到git不仅在我的机器上很慢，而且在分段环境中部署应用程序现在需要大约3个小时。
所以修复应该是会影响服务器的东西，而不仅仅是存储库的用户。
你垃圾收集？
git gc
即使对于小回购，这在速度上也有显着的差异。
说明
Git真的很擅长处理小文本文件的巨大历史，因为它可以高效地存储它们及其更改。 同时，git在二进制文件上非常糟糕，并且会天真地存储单独的文件副本（ 至less默认 ）。 如你所见，资源库变得庞大，然后变得很慢。
这是DVCS之间的一个常见问题，因为每次克隆时都下载每个文件的版本（“整个版本库”），这就加剧了这个问题。 Kiln的家伙正在开发一个插件来处理这些大文件，就像Subversion一样，它只能按需下载历史版本。
解
这个命令会列出大小大于等于5MB的当前目录下的所有文件。
find . -size +5000000c 2>/dev/null -exec ls -l {} \;
如果你想从存储库的整个历史中删除文件，你可以使用这个想法与git filter-branch一起走过历史，摆脱所有大文件的痕迹。 这样做后，库的所有新克隆将变得更加精简。 如果您想在没有克隆的情况下build立一个存储库，可以在手册页上find说明 （请参阅“缩小存储库的检查表”）。
git filter-branch --index-filter \ 'find . -size +5000000c 2>/dev/null -exec git rm --cached --ignore-unmatch {} \;'
一个警告的话 ：这将使您的存储库与其他克隆不兼容 ，因为树木和索引有不同的文件签入; 你将无法再推或拉他们了。
这是一个审查修订旨在减less消极和煽动性：
当涉及到不是逐行文本文件的文件时，Git有一个众所周知的弱点。 目前还没有解决scheme，核心Git团队没有公布计划来解决这个问题。 如果您的项目很小，比如100 MB左右，则有解决方法。 有git项目的分支来解决这个可伸缩性问题，但是这些分支在这个时候还不成熟。 其他一些版本控制系统没有这个特定的问题。 在决定是否selectgit作为你的版本控制系统时，你应该把这个问题当作许多因素之一。
关于二进制文件和git处理它们的方式没有什么特别的。 将文件添加到git存储库时，会添加一个头文件，并使用zlib压缩该文件，并在SHA1哈希后重命名该文件。 无论文件types如何，这都是一样的。 在zlib压缩中没有任何东西会使二进制文件出现问题。
但是在某些时候（gc），Git开始考虑delta压缩内容的可能性。 如果gitfind类似的文件（文件名等），它将把它们放在RAM中并开始压缩在一起。 如果你有100个文件，其中每个文件都是50Mb，那么它会尝试同时在内存中放入5GB。 为此，你必须添加一些更多的工作。 您的计算机可能没有这个数量的RAM，它开始交换。 这个过程需要时间。
您可以限制增量压缩的深度，以便进程不使用那么多的内存，但结果是压缩效率较低。 （core.bigFileThreshold，delta属性，pack.window，pack.depth，pack.windowMemory等）
所以有很多人认为你可以做大量的文件使git工作得很好。
加快速度的一种方法是使用--depth 1标志。 有关详细信息，请参阅手册页。 我不是一个很棒的git guru，但是我相信这是说p4 get或者svn get ，就是它只给你最新的文件，而不是“把所有文件的所有修改全部给我时间“这是git clone做的。
你有没有告诉git这些文件是二进制的？
例如将*.ext binary添加到您的存储库的.gitattributes
您也可以将BFG Repo Cleaner视为更简单的方式来清理大型文件。
自2008年以来，我一直在使用Git，在Windows和GNU / Linux上，我跟踪的大部分文件都是二进制文件。 我的一些回购是几GB，包含Jpeg和其他媒体。 我有很多电脑在家里和工作中运行Git。
我从未有过原帖所描述的症状。 但就在几个星期前，我在一台旧的Win-XP笔记本电脑上安装了MsysGit，几乎无论我做了什么，都让Git停下来了。 即使只有两个或三个小文本文件的testing是慢得可笑的。 我们正在谈论10分钟来添加less于1K的文件…似乎git进程永远活着。 其他一切按照预期在这台电脑上工作。
我从最新的版本降级到1.6的东西，问题没有了…
我有同样品牌的其他笔记本电脑，也由同一个IT部门安装的Win-XP形成相同的图像，在哪里Git工作正常，无论版本…所以一定有一些奇怪的特定电脑。
我也做了一些二进制文件和压缩testing。 如果你有一个BMP图片，你做了一些小的改变，并提交它们，git gc将压缩得很好。 所以我的结论是，压缩并不取决于文件是否是二进制文件。
只需将文件设置为被忽略。 请参阅下面的链接：
这是因为git不可扩展。
这是git被git倡导所淹没的一个严重的限制。 searchgit邮件列表，你会发现有数百名用户想知道为什么只有100 MB的图片（比如网站或应用程序）会让git瘫痪。 问题似乎是几乎所有的git都依赖于他们称之为“包装”的优化。 不幸的是，除了最小的文本文件（即源代码）之外，打包效率都不高。 更糟糕的是，随着历史的增长，效率越来越低。
这真是git中令人尴尬的缺陷，被吹捧为“快”（尽pipe缺乏证据），git开发人员也很清楚这一点。 他们为什么不修理它？ 你会发现Git开发人员在git邮件列表上找不到答案，因为他们的Photoshop文档（* .psd）是专有格式。 是的，这真的很糟糕。
结果如下：
将git用于小型的源代码项目，对于这些项目您不希望设置单独的回购。 或者对于那些想要利用git的copy-the-entire-repo模型的分散开发的小型源代码项目。 或者当你只是想学习一个新的工具。 所有这些都是使用git的好理由，学习新工具总是很有趣。
如果你有一个庞大的代码库，二进制文件，巨大的历史logging等，不要使用git。只有一个我们的回购是结核病。 Git无法处理它。 VSS，CVS和SVN处理它就好了。 （SVN膨胀了，但是。）
另外，给git时间去成熟。 现在还不成熟，但势头很好。 最后，我认为Linus的实际性质将会克服OSS的纯粹主义者，git最终将会在更大的领域中得到应用。
