跟踪大型二进制文件时,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视为更简单的方式来清理大型文件。

https://rtyley.github.io/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将压缩得很好。 所以我的结论是,压缩并不取决于文件是否是二进制文件。

只需将文件设置为被忽略。 请参阅下面的链接:

http://help.github.com/git-ignore/

这是因为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最终将会在更大的领域中得到应用。