Git pull 非常慢...为什么？

问题描述 投票：0回答：8

注意我已经研究了 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
资产） 当我意识到这一点时，我使用 
git rm
将它们从存储库中删除（当然，
git add
、
git commit
和 
git push
到上游）。

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

我有两个问题：

  • 为什么会发生这种情况？
  • 如何修复我的存储库？

注意：我是唯一使用并推送此存储库的人。

git version-control repository
8个回答
46
投票

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

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

sudo service ssh restart

更多信息这里。

17
投票

我在处理数千个小文件时也遇到过同样的问题。 为我解决这个问题的方法是在 git repo 的配置中设置 postbuffer

git config http.postBuffer 524288000

不再以 18KB/s 上传，而是突然达到全带宽

12
投票

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

git config --global protocol.version 2
5
投票

问题出在 

EmberJS
应用程序目录中。它包含 
node_modules
和 
bower_components
目录，其中保存了 
GruntJS
用于构建我的 JS 和 CSS 资源的第三方库。

其中每个都包含许多文件和目录..考虑到依赖关系树包含数百个大小不等的库，从小（几个文件）到大（许多文件）。

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

5
投票

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

3
投票

以防万一有人偶然发现这个线程，在删除你的 .git 文件夹之前，尝试重新启动你的 wifi，这可能只是你的 wifi 连接问题。

2
投票

不仅协议 v2 有帮助，提交图（这里提到）也会有帮助。

在 Git 2.34（2021 年第 4 季度）中，加载参考提示以准备“

git fetch-pack
”(man) 中的共同祖先协商已通过利用可用的提交图进行了优化。

请参阅提交 3e5e6c6（2021 年 8 月 4 日），作者：Patrick Steinhardt (

pks-t
)。
（由 Junio C Hamano -- 
gitster
-- 合并于 commit 1b2be06，2021 年 8 月 24 日）

fetch-pack
：通过提交图加速引用加载

签字人：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'
0
投票

我使用的是 Linux Mint、GitLab 和 GitHub。之前我在 pull/fetch 方面没有任何问题，但突然之间我只在 GitLab 方面遇到了问题。读完这篇文章后，我明白它可能与 SSH 和 IPv4/6 有关。

当我在 https://whatismyipaddress.com/ 上看到该网站找不到我的 IPv6 地址时，我重新启动了路由器。现在一切都很好。

所以在开始更改设置之前，请尝试这个简单的解决方案

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.