Git pull 很慢……为什么？答案

【问题标题】：Git pull is very slow... Why?Git pull 很慢……为什么？
【发布时间】：2014-03-29 05:07:42
【问题描述】：

注意我已经研究了git-is-very-very-slow 问题，但在他们的情况下，原因是大的二进制文件 - 而在我的存储库中只有 PHP/JS/HTML/CSS 代码（没有二进制文件）和存储库中最大的文件大约 800 KB。

我更改了一个文件（几行），然后是 git add . 和 git commit -m "msg"，然后是 git push origin master。

在其他机器上，当我执行git pull origin master 时，它会下载几 MiB 的数据，计算增量和应用更改需要 2 多分钟。这里出了点大问题。

我怀疑最近的一些操作可能会导致这种情况：

最近，我不小心添加了许多供应商资产 (bower_components assets) 当我意识到这一点时，我已经使用 git rm 将它们从存储库中删除（当然还有 git add、git commit 和 git push 到上游）。

那是几天前的事了，我现在遇到的问题就是从那个时候开始出现的。

我有两个问题：

为什么会这样？
如何修复我的存储库？

注意：我是唯一一个使用并推送到这个 repo 的人。

【问题讨论】：

尝试git ls-files 查看所有签入 git 的文件。可以了解正在发生的事情
总共有 530 个文件。我查看了列表，所有文件都应该在那里（并且没有一个大于 800KB）
另一台机器是否已经有您删除供应商资产的更改？如果没有，它可能需要在添加和删除它们的地方提取修订，因为只需git rming 他们就会在历史记录中留下添加内容。如果您随后拉取新的更改，它是否仍然很慢？
在意外添加文件后，我在目标机器上进行了拉动……这就是我意识到我的错误的时候……所以我去了我的源机器，做了git rm，向上游推送，然后回到我的目标机器并拉出
然而，从那一刻起，目标机器上的每次后续拉取都很慢...我知道它必须在第一次拉取该提交时下载文件..但我希望它在所有后续拉动上快速工作（无论我是否使用git rm）

标签： git version-control repository

【解决方案1】：

不仅协议 v2 会有所帮助，提交图 (mentioned here) 也会有所帮助。

在 Git 2.34（2021 年第四季度）中，通过利用提交图优化了在 "git fetch-pack"^(man) 中加载 ref 提示以准备共同祖先协商可用。

参见Patrick Steinhardt (pks-t)commit 3e5e6c6（2021 年 8 月 4 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 1b2be06，2021 年 8 月 24 日）}

fetch-pack: 通过提交图加速 refs 的加载

^{签字人：Patrick Steinhardt}

在进行引用协商时，git-fetch-pack(1) 会从磁盘加载所有引用，以确定它与远程存储库有哪些共同提交。
但是，这在具有许多引用的存储库中可能会非常昂贵：在具有大约 220 万个引用的真实存储库中，通过其 ID 获取单个提交大约需要 44 秒。

主导加载时间的是对提交引用的对象的解压缩和解析。
鉴于在这种情况下我们只关心提交（或可以剥离到一个的标签），因此通过切换解析逻辑以使用提交图以防万一我们有一个可用的提交图，因此可以轻松获得性能提升。像这样，我们避免访问对象数据库来解析这些提交，而是只从提交图加载它们。
这导致在具有 220 万个引用的存储库中执行 git-fetch^(man) 时显着提高性能：
Benchmark #1: HEAD~: git fetch $remote $commit
  Time (mean ± σ):     44.168 s ±  0.341 s    [User: 42.985 s, System: 1.106 s]
  Range (min … max):   43.565 s … 44.577 s    10 runs

Benchmark #2: HEAD: git fetch $remote $commit
  Time (mean ± σ):     19.498 s ±  0.724 s    [User: 18.751 s, System: 0.690 s]
  Range (min … max):   18.629 s … 20.454 s    10 runs

Summary
  'HEAD: git fetch $remote $commit' ran
    2.27 ± 0.09 times faster than 'HEAD~: git fetch $remote $commit'

【讨论】：

【解决方案2】：

我尝试了这个线程中的所有解决方案，但没有运气。我在同事的建议下尝试使用 git 协议 2，结果非常有效（从等待 3 分钟拉/推开始到几秒钟）

git config --global protocol.version 2

【讨论】：

【解决方案3】：

我有同样的问题。对我来说，这是一个 IPv4/IPv6 问题。我修复了它强制 SSH 使用 IPv4。

在 /etc/ssh/ssh_config 中设置“AddressFamily inet”以强制 IPv4 连接。然后重启ssh客户端sudo service ssh restart

更多信息here。

【讨论】：

这就是解决方案！！我终于通过这个解决了这个问题。您可以尝试git fetch -4 或git push -4 看看是否真的解决了问题，然后再将其添加到 ssh_config。
@Arst git fetch -4 是什么意思？
@kajibu 这意味着使用 IPv4。可以是 -4，--ipv4。对于 IPv6：-6 --ipv6。
这个解决方案对我有用。但是不需要重启服务。
@Arst 解决方案为我节省了很多痛苦。无需重启

【解决方案4】：

如果有人偶然发现了这个帖子，在删除你的 .git 文件夹之前，尝试重新启动你的 wifi，这可能只是你的 wifi 连接问题。

【讨论】：

我不明白为什么这个答案被否决了那么多。这可能是某些人的解决方案。路由器/调制解调器往往会不时出现故障，从而导致性能或连接问题。
由于这个问题可能是由于带宽不足引起的，所以这个解决方案对我有用。

【解决方案5】：

我在处理数千个小文件时遇到了同样的问题。为我解决的问题是在 git repo 的配置中设置后缓冲区

git config http.postBuffer 524288000

它没有以 18KB/s 的速度上传，而是突然达到了全带宽

【讨论】：

【解决方案6】：

我有过类似的经历——在我的本地 Mac OSX 和我的 Linux / Apache 服务器上，git pull 和 push 突然开始运行极其缓慢，需要十分钟或更长时间。我在我的 Mac 上删除了 repo 的本地副本，然后重新克隆它，它开始运行良好。在服务器上做了同样的事情，一切都很好。我想它被某种方式损坏了？

【讨论】：

【解决方案7】：

问题出在EmberJS app 目录中。它包含 node_modules 和 bower_components 目录，这些目录保存了 GruntJS 用于构建我的 JS 和 CSS 资产的第三方库。

每个都包含许多文件和目录。考虑到依赖树包含数百个大小从小（很少文件）到大胖（很多文件）的库。

删除这些目录并忽略它们后，git 存储库再次快速运行。

【讨论】：

fetch-pack: 通过提交图加速 refs 的加载

`fetch-pack`: 通过提交图加速 refs 的加载