当git repos变得很大时，哪些操作会变慢?为什么？
这个问题在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?
所以，我不得不再问一遍：
基本git操作(提交、推送、拉入、添加、获取、分支、合并、签出)的
- ，当repos变大时，哪些操作会变慢(注意: repos，而不是此问题的文件)
和,
- 为什么每个操作都取决于回购大小(或不取决于)？
我现在不关心如何修复那个。我只关心哪些动作的性能会受到影响，以及根据当前git架构的推理。
编辑以澄清：
很明显，例如，git clone将是回购的大小的o(n)。
然而，我不清楚git pull是否相同，因为从理论上讲，只看差异是可能的。
Git在幕后做了一些不平凡的事情，我不确定是什么时候做的。
Edit2：
我在this上找到一篇文章，说
如果您的存储库中有大的、不可区分的文件，如二进制文件，则每次提交对该文件的更改时，您都会在存储库中保留该文件的完整副本。如果您的存储库中存在这些文件的许多版本，它们将极大地增加签出、分支、 fetch和您的代码的时间。
我不明白为什么分支需要比O(1)更多的时间，我也不确定列表是否已经满了。(例如，拉动怎么办？)
回答 2
Stack Overflow用户
发布于 2019-07-22 00:35:27
然而，我并不清楚git pull是否会是相同的，因为理论上只看不同是可能的。
从Git2.23 (Q3 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.用于
push命令的 - 和pack-file tree discovery。
它们将显著增加签出、分支、获取和克隆的时间
这不会是因为操作不是O(1)。
这与执行这些操作时要在周围传输/复制的大量二进制文件的大小有关。
创建一个新的分支仍然非常快，但是当你必须更新那些二进制文件时，切换到它可能会很慢，仅仅从i/o的角度来看(复制/更新/删除大文件)。
Stack Overflow用户
发布于 2019-07-22 00:02:59
我看到了你已经开放讨论的两个主要问题。首先，当repos变得更大时，您会问到哪些Git操作变慢了。答案是，随着repo变得越来越大，大多数Git操作都会变慢。但是，那些涉及到与远程存储库交互的操作会让Git看起来明显变慢。对您来说，直觉应该是，如果存储库膨胀，那么克隆、拉取和推送等操作将需要更长的时间。
您提到的另一个问题是，是否应该首先提交大的二进制文件。当您进行提交时，提交中的每个文件的副本将被压缩并添加到树中。二进制文件往往不能很好地压缩。因此，随着时间的推移，添加大型二进制文件可能会导致存储库膨胀。事实上，许多团队会配置他们的遥控器(例如GitHub)来阻止任何包含大型二进制文件的提交。
https://stackoverflow.com/questions/57134772
复制相似问题