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

Question

请注意，我已经研究了“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”时，它会下载几MB的数据，并且需要超过2分钟来计算差异并应用更改。这里出现了一些可怕的问题。

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

最近，我不小心添加了许多供应商资产（“bower_components”资产）。

当我意识到这一点时，我使用了“git rm”将其从仓库中删除（当然，还要使用“git add”、“git commit”和“git push”将更改推送到上游）

那是几天前，我现在的问题始于那个时候。

我的两个问题是：

1. 为什么会发生这种情况？ 2. 如何修复我的仓库？

注意：我是唯一一个使用和推送到这个仓库的人。

- ioleo

---

尝试使用 git ls-files 命令查看所有已提交到 Git 的文件。这可能会让你了解正在发生的情况。 - Akash

总共有530个文件.. 我已经检查了列表，所有文件都应该在那里（而且没有一个文件超过800KB） - ioleo

另一台机器是否已经有你移除供应商资产的更改？如果没有，它可能需要拉取添加和删除修订版本，因为仅仅使用git rm命令会在历史记录中留下这些添加。如果进行后续的新更改拉取，速度是否还是很慢？ - Wooble

在意外添加文件后，在目标机器上执行了pull操作...这时我意识到了我的错误...所以我回到我的源机器，执行了git rm命令，推送到上游，然后返回到目标机器并执行了pull操作。 - ioleo

然而，自从那一刻起，每次对目标机器的拉取都变得缓慢了...我知道第一次拉取该提交时必须下载文件..但是我期望它在所有后续的拉取中都能快速工作（无论我是否执行git rm）。 - ioleo

注意：所有更改都在源计算机上进行，然后推送到版本控制服务器，然后在目标计算机上拉取 --> 只有目标计算机上的拉取速度较慢，推送速度很快。 - ioleo

Answer 1

我遇到了同样的问题。对我来说，这是一个IPv4 / IPv6问题。我通过强制SSH使用IPv4来解决它。

在/etc/ssh/ssh_config中设置"AddressFamily inet"以强制使用IPv4连接。然后重新启动SSH客户端 sudo service ssh restart

更多信息在此处。

- JGL

---

这就是解决方案!! 我最终通过这个解决了问题。在将其添加到ssh_config之前，您可以尝试使用git fetch -4或git push -4查看是否真正解决了问题。 - Arst

@Arst，git fetch -4 是什么意思？ - kajibu

@kajibu的意思是使用IPv4，可以用选项"-4"或"--ipv4"表示。对于IPv6，可以用选项"-6"或"--ipv6"表示。 - Arst

这个解决方案对我有效。但是没有必要重新启动服务。 - twan163

可能是DNS提供了错误的AAAA记录。与网络管理员解决IPv6问题可以帮助其他客户端。 - undefined

Answer 2

在处理成千上万个小文件时，我也遇到了同样的问题。对我有用的方法是在git仓库的配置中设置postbuffer。

git config http.postBuffer 524288000

与其以每秒18KB的速度上传，它突然达到了最大带宽

- Sander Stad

Answer 3

我尝试了本帖中的所有解决方案都没有成功。我的同事建议我使用git协议2，结果非常有效（从等待3分钟开始拉/推变成了几秒钟）。

git config --global protocol.version 2

- Eli Berkowitz

Answer 4

问题出在EmberJS应用程序目录中。它包含有node_modules和bower_components目录，这些目录里面都是GruntJS用来构建JavaScript和CSS文件所需的第三方库。

每个目录都包含许多文件和子目录，依赖树包含了数百个大小不等的库，从小型（几个文件）到大型肥胖（许多文件）不等。

删除这些目录并将其忽略后，git仓库再次快速工作。

- ioleo

Answer 5

我有类似的经历--git pull和push突然变得极其缓慢，需要十分钟或更长时间才能完成，在我的本地Mac OSX和Linux / Apache服务器上都是如此。我删除了Mac上的本地存储库副本，并重新克隆了一份，它开始正常运行。在服务器上也做了同样的事情，一切正常。我想这可能是某种文件损坏导致的？

- NessBird

Answer 6

如果有人偶然进入这个线程，请在删除.git文件夹之前尝试重新启动您的wifi，这可能只是您的wifi连接问题。

- ATHER

---

我不明白为什么这个答案被踩得那么多。这可能是一些人的解决方案。路由器/调制解调器往往会时不时出现故障，导致性能或连接问题。 - Can Baycay

由于带宽不足可能导致此问题，因此这个解决方案对我有效。 - Jonathan Rys

帮助了，谢谢。 - shukshin.ivan

Answer 7

不仅协议v2会有帮助，提交图(在这里提到)也会有帮助。

随着Git 2.34(Q4 2021)的推出，加载引用提示以准备在"git fetch-pack"^(手册)中进行共同祖先谈判已经通过利用提交图进行了优化。

查看提交 3e5e6c6 (2021年8月4日) 由Patrick Steinhardt (pks-t)提交。
^{(由Junio C Hamano -- gitster --在提交 1b2be06中合并，2021年8月24日)}

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

^{由Patrick Steinhardt签署}

When doing reference negotiation, git-fetch-pack(1) is loading all refs from disk in order to determine which commits it has in common with the remote repository.
This can be quite expensive in repositories with many references though: in a real-world repository with around 2.2 million refs, fetching a single commit by its ID takes around 44 seconds.

Dominating the loading time is decompression and parsing of the objects which are referenced by commits.
Given the fact that we only care about commits (or tags which can be peeled to one) in this context, there is thus an easy performance win by switching the parsing logic to make use of the commit graph in case we have one available.
Like this, we avoid hitting the object database to parse these commits but instead only load them from the commit-graph.
This results in a significant performance boost when executing git-fetch^(man) in said repository with 2.2 million refs:

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'

- VonC

Answer 8

我之前一直在使用Linux Mint、GitLab和GitHub。以前在进行pull/fetch操作时没有遇到任何问题，但突然间只有在GitLab上出现了问题。在阅读了这个帖子后，我明白可能与SSH和IPv4/6有关。

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

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

- Shlomi Yahbes

Answer 9

这可能是由于您使用的git协议引起的。 我将gitlab项目的url切换为https，慢速的噩梦就消失了！

您可以编辑您的repo .git/config并更改为https url，或者通过命令行进行操作：

git remote set-url https://{server}@gitlab.com/{user}/{project}.git`

- Noam Manos