我的项目已经六个月大了，而git非常慢。我们跟踪大约30个文件，大小为5 MB到50 MB。这些是二进制文件，我们将其保存在git中。我相信这些文件会使git变慢。

有没有办法杀死存储库中所有大小> 5MB的文件。我知道我会丢失所有这些文件，我也可以。

理想情况下，我想要一个列出所有大文件（> 5MB）的命令。我可以看到列表，然后说可以，删除这些文件并使git更快。

我应该提到git不仅在我的机器上运行缓慢，而且在暂存环境中部署该应用程序大约需要3个小时。

因此，修复程序应该会影响服务器，而不仅影响存储库的用户。

你有垃圾吗？

git gc

即使对于小型仓库，这也会在速度上产生重大差异。

说明

Git非常擅长处理小型文本文件，因为它可以有效地存储它们及其更改。同时，git对于二进制文件非常不利，并且会天真的存储文件的单独副本（至少默认情况下）。正如您所观察到的，存储库变得巨大，然后又变慢。

这是DVCS中的一个常见问题，每次克隆时您都会下载每个文件的每个版本（“整个存储库”），这一事实使情况更加恶化。Kiln的家伙正在开发一个插件，以将这些大文件更像Subversion，后者仅按需下载历史版本。

解

该命令将列出当前目录下所有文件，文件大小> = 5MB。

find . -size +5000000c 2>/dev/null -exec ls -l {} \;

如果要从存储库的整个历史记录中删除文件，则可以将此想法与git filter-branch历史记录一起使用，并摆脱大文件的所有痕迹。完成此操作后，存储库的所有新克隆都将变得更精简。如果要精简存储库而不进行克隆，请在手册页上找到说明（请参见“收缩存储库清单”）。

git filter-branch --index-filter \
    'find . -size +5000000c 2>/dev/null -exec git rm --cached --ignore-unmatch {} \;'

警告：这将使您的存储库与其他克隆不兼容，因为树和索引已签入不同的文件；您将无法再从中推拉。

这是经过审查的修订版，旨在减少负面影响和煽动性：

对于不是逐行文本文件的文件，Git有一个众所周知的弱点。目前还没有解决方案，核心git团队也没有宣布解决此问题的计划。如果您的项目很小（例如100 MB左右），则有解决方法。git项目存在分支来解决此可伸缩性问题，但是这些分支目前尚不成熟。其他一些版本控制系统没有此特定问题。在决定是否选择git作为版本控制系统时，应该将这个问题视为众多因素之一。

关于二进制文件和git处理它们的方式没有任何具体说明。将文件添加到git存储库时，将添加标头，并使用zlib压缩文件，并在SHA1哈希之后重命名。无论文件类型如何，这都是完全相同的。zlib压缩中没有任何内容使二进制文件有问题。

但是在某些时候（pushing，gc），Git开始考虑增量压缩内容的可能性。如果git找到相似的文件（文件名等），则将它们放在RAM中并开始将它们压缩在一起。如果您有100个文件，并且每个文件都说50Mb，它将尝试同时在内存中放入5GB。为此，您必须添加更多内容才能使工作正常。您的计算机可能没有此数量的RAM，并且它开始交换。该过程需要时间。

您可以限制增量压缩的深度，以使该进程不使用那么多的内存，但结果是压缩效率较低。（core.bigFileThreshold，delta属性，pack.window，pack.depth，pack.windowMemory等）

因此，有很多想法可以使git在大型文件中很好地工作。

一种加快速度的方法是使用该--depth 1标志。有关详细信息，请参见手册页。我不是一个很棒的git大师，但我相信这相当于ap4 get或an svn get，即它只给您提供最新文件，而不是“一直给我所有文件的所有修订”是什么git clone呢。

您是否告诉git这些文件是二进制文件？

例如，添加*.ext binary到您存储库的.gitattributes

您也可以将BFG Repo Cleaner视为清理大型文件的更快捷，更简便的方法。

https://rtyley.github.io/bfg-repo-cleaner/

自2008年以来，我一直在Windows和GNU / linux上运行Git，我跟踪的大多数文件都是二进制文件。我的一些存储库有几个GB，其中包含Jpeg和其他媒体。我在家中和工作中都有许多运行Git的计算机。

我从未有过原始帖子所描述的症状。但是就在几周前，我在旧的Win-XP笔记本电脑上安装了MsysGit，几乎我所做的一切都使git停顿了下来。甚至只用两个或三个小文本文件进行测试的速度也非常慢。我们正在谈论10分钟以内添加小于1k的文件...看来git进程永远都活着。其他一切都在这台计算机上按预期工作。
我从最新版本降级到1.6时，问题消失了……
我有其他相同品牌的笔记本电脑，并且同一IT部门安装了Win-XP，形成了相同的映像，无论版本如何，Git都可以正常工作。 ..所以那台特定的计算机肯定有些奇怪。

我还对二进制文件和压缩进行了一些测试。如果您有一个BMP图片，并且对其进行了很小的更改并提交，则git gc将很好地压缩。因此，我的结论是，压缩不取决于文件是否为二进制文件。

只需将文件设置为忽略即可。请参阅下面的链接：

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

那是因为git无法扩展。

这是git倡导者淹没的git中的严重限制。搜索git邮件列表，您会发现数百名用户想知道为什么仅仅100 MB的图像（例如，用于网站或应用程序）就使git屈服。问题似乎在于，几乎所有的git都依赖于它们称为“打包”的优化。不幸的是，除了最小的文本文件（即源代码）以外，所有其他文件的打包效率都不高。更糟糕的是，随着历史的增长，它的效率越来越低。

这确实是git中一个令人尴尬的缺陷，被吹捧为“快速”（尽管缺乏证据），而git开发人员也很清楚。他们为什么不解决呢？您会在git邮件列表中找到来自git开发人员的回复，这些开发人员由于他们的Photoshop文档（* .psd）是专有格式而无法识别问题。是的，真的很糟糕。

结果如下：

将git用于您不希望为其建立单独的存储库的微型，仅源代码的项目。或对于小型源代码项目，您想利用git的分散式开发的“整个副本库”模型。或者，当您只是想学习一种新工具时。所有这些都是使用git的充分理由，学习新工具总是很有趣。

如果您有大量的代码库，二进制文件，庞大的历史记录等，请不要使用git。我们的存储库之一就是TB。Git无法处理。VSS，CVS和SVN可以很好地处理它。（不过，SVN膨胀了。）

另外，给git时间使其成熟。它仍然不成熟，但是势头很大。随着时间的推移，我认为Linus的实用性将克服OSS的纯粹主义者，而git最终将在更大的领域中可用。