时间戳

首页 > 解决方案 > 当 git repos 变大时，哪些操作会变慢，为什么？

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

问题描述

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

例如：

所以，我不得不再次问：

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

和，

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

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

编辑澄清：

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

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

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

编辑2：

我找到了这篇文章，说明

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

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

标签： git

解决方案

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

从 Git 2.23（2019 年第三季度）开始，它不是O(N)，而是O(n log(N))：请参阅“ Git 获取一个具有正常名称的分支，一次获取大写字母”。

主要问题是日志图遍历，检查我们有什么和没有什么（或计算强制更新状态）。
这就是为什么对于大型存储库，最近的 Git 版本引入了：

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

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

推荐阅读