当 git repos 变大时，哪些操作会变慢，为什么？

Question

在 SO 和其他地方以各种形式提出了这个问题，但我找不到让我满意的答案，因为没有人列出有问题/无问题的操作/命令，也没有人给出技术原因的完整解释速度命中。

例如：

• Why can't Git handle large files and large repos
• Why git operations becomes slow when repo gets bigger
• Git is really slow for 100,000 objects. Any fixes?

所以，我不得不再问一遍：

1. 在基本 git 操作（提交、推送、拉取、添加、获取、分支、合并、签出）中，当存储库变大时，哪些操作会变慢（注意：此问题的存储库，而不是文件）

还有，

1. 为什么每个操作都取决于（或不）repo 大小？

我现在不关心如何解决这个问题。 我只关心哪些动作的性能受到影响，以及根据当前 git 架构的推理。

---

编辑澄清：

很明显，例如git clone，将是 o(n) 的 repo 大小。

但我不清楚git pull 是否相同，因为理论上可以只查看差异。

Git 在幕后做了一些不平凡的事情，我不确定何时何地。

---

编辑2：

我找到this的文章，说明

如果您的存储库中有大型、不可比较的文件（例如二进制文件），您可以 每次提交时都会在您的仓库中保留该文件的完整副本 对文件的更改。如果这些文件的多个版本存在于您的 repo，他们将大大增加结帐、分支的时间， 获取并克隆您的代码。

我不明白为什么分支应该花费超过 O(1) 的时间，而且我也不确定列表是否已满。 （例如，拉动呢？）

Answer 1

但我不清楚git pull 是否相同，因为理论上可以只查看差异。

从 Git 2.23（2019 年第三季度）开始，它不再是 O(N)，而是 O(n log(N))：参见“Git fetch a branch once with a normal name, and once with capital letter”。

主要问题是日志图遍历，检查我们有什么和没有什么（或computing forced update status）。
这就是为什么对于大型存储库，最近的 Git 版本引入了：

• reachability bitmap,
• commit graph,
• loose cache,
• Commit Graphs Chains。
• pack-file tree discovery 用于push 命令。

它们将大大增加结帐、分支、获取和克隆的时间

这不会是因为操作不是O(1)。
这与执行这些操作时要传输/复制的大量二进制文件的大小有关。
创建新分支仍然非常快，但是当您必须更新那些二进制文件时切换到它可能会很慢，仅从 i/o 角度来看（复制/更新/删除大文件）。

Answer 2

我看到您提出了两个主要问题供讨论。首先，您要问随着 repos 变大，哪些 Git 操作会变慢。答案是，随着 repo 变大，大多数 Git 操作会变慢。但是让 Git 看起来明显变慢的操作是那些涉及与远程存储库交互的操作。您应该很直观地知道，如果 repo 膨胀，那么克隆、拉取和推送等操作会花费更长的时间。

您提到的另一个问题是是否应该首先提交大型二进制文件。当您进行提交时，提交中每个文件的副本都会被压缩并添加到树中。二进制文件往往不能很好地压缩。因此，随着时间的推移，添加大型二进制文件可能会导致您的存储库膨胀。事实上，许多团队会配置他们的远程（例如 GitHub）来阻止任何此类包含大型二进制文件的提交。