git repo中大量分支的影响？

Question

有谁知道有很多分支(2000+)的git仓库的影响是什么？由于拥有那么多分支,git pull或git fetch是否会变慢？如果存在差异,请提供基准.

Answer 1

正如其他人所指出的那样,分支和其他引用只是文件系统中的文件(除了由于打包引用而不完全正确)并且非常便宜,但这并不意味着它们的数量不会影响性能.例如,Git邮件列表中的大量refs线程的糟糕推送性能最近(2014年12月)Git性能受到存储库中20k refs影响的示例.

如果我没记错的话,几年前ref处理的某些部分是O(n²),但从那以后就可以很好地修复了.2012年3月有一个回购讨论帖子,其中包含一些可能有用的详细信息,如果可能是日期和特定于JGit的.

同样有点过时的Scaling Gerrit文章谈到了(其中包括)高参考值的潜在问题,但也注意到几个网站都有超过100k refs的gits.我们有一个约150k refs的git,我认为我们没有看到任何性能问题.

拥有大量引用的一个方面是在一些Git事务开始时ref引用的大小.上述150k ref git的广告大小约为10 MB,即每个git fetch操作都将下载该数据量.

所以是的,不要完全忽略这个问题,但你不应该仅仅因为2000 refs而失去任何睡眠.

Answer 2

2015年3月：我没有基准，但git fetch即使上游回购拥有大量分支，也可以确保价格仍然合理的一种方法是，使用默认的refspec而不是默认的refspec。

fetch = +refs/heads/*:refs/remotes/origin/*

您可以根据需要向远程添加任意数量的获取引用规范，用更具体的规范有效地替换上面包含的所有引用规范，以仅包括您实际需要的分支（即使远程仓库有数千个）。

fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/br*:refs/remotes/origin/br*
fetch = +refs/heads/mybranch:refs/remotes/origin/mybranch
....

2018年4月：git fetch将在Git 2.18（2018年第二季度）中得到改善。

参见Takuto Ikuta（）提交024aa46（2018年3月14日）。^{（通过合并JUNIOÇ滨野- -在提交5d806b7，2018年4月9日）}atetubou
gitster

fetch-pack.c：使用oidset检查是否存在松散对象

当从具有大量引用的存储库中获取数据时，由于要检查本地存储库中每个refs是否存在打包和松散的对象，因此'git fetch'最终会执行很多lstat(2)对不存在的松散形式的操作，这使其运行缓慢。

而不是进行lstat(2)宣传以查看远程对象是否以松散形式存在的ref的调用，而是先枚举hashmap中所有现有的松散对象，然后使用ref来检查它们的存在，如果ref的数量大于松散物体的数量。

使用此补丁程序，铬存储库的lstat(2)调用git fetch次数从411412减少到13794，它具有超过480000的远程引用。

我记录了git fetch在带有SSD的linux上铬存储库何时发生fetch-pack 3次的时间统计信息。

* with this patch
8.105s
8.309s
7.640s
avg: 8.018s

* master
12.287s
11.175s
12.227s
avg: 11.896s

在具有较慢lstat（2）的MacBook Air上。

* with this patch
14.501s

* master
1m16.027s

git fetch 在慢速磁盘上将大大改善。

请注意，在packfile中使用的此哈希图确实在Git 2.24（2019年第四季度）中得到了改进

见提交e2b5038，提交404ab78，提交23dee69，提交c8e424c，提交8a973d0，提交87571c3，提交939af16，提交f23a465，提交f0e63c4，提交6bcbdfb，提交973d5ee，提交26b455f，提交28ee794，提交b6c5241，提交b94e5c1，提交f6eb6bd，提交d22245a，提交d0a48a0，提交12878c8，提交e010a41（2019年10月6日）作者黄（Eric Wong）（ele828）。
建议者：Phillip Wood（phillipwood）。
^{（由Junio C gitsterHamano合并--在5efabc7号提交中，2019年10月15日）}

例如：

packfile：使用hashmap_entry在delta_base_cache_entry

^{签名者：黄家强签名
者：Derrick Stolee}

此hashmap_entry_init函数旨在采用hashmap_entry结构指针，而不是哈希图结构指针。

这没有引起注意，因为hashmap_entry_init采用了“ void *” arg而不是“ struct hashmap_entry *”，并且hashmap结构更大，可以转换为hashmap_entry结构而不会破坏数据。

这具有在64位系统上将a的大小delta_base_cache_entry从104字节减少到72字节的有益副作用。