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