Git 2.33加入新的整合策略可提升整合性能达9,000倍

Git 2.33现在已经推出,有不少用户不会有太大感觉的背景修改,不过仍有新功能可以提升开发者的日常使用体验,像是这个版本添加一种称为merge-ort的整合策略,能解决整合正确性和性能方面的问题,并且作为未来新功能的基础。

GitHub解释,目前Git在两分支整合时,使用称为整合递归(Merge-Recursive)的方法,这个方法有两个好处,在交叉整合的情况下,政策可以对每个可能的基础进行一系列整合,这能够解决政策产生冲突的情况,而且能够侦测每个分支重命名的文件,当一个文件被修改,又被另一方重命名,整合递归能够将修改应用于重命名的目标。

一直以来整合递归都是Git默认配置,但是该方法存在一些不可忽视的缺点。GitHub提到,由于整合递归起初是当作外部Python脚本来开发,其使用Git管线命令来检查资料,后来使用C语言重写,虽然速度获得提升,但是其程序代码组织和数据结构仍然承袭旧版本,主要依靠Git索引和工作树运行,导致常年出现一些难解的bug和极端案例问题。

整合递归使得优化和扩展程序代码变得困难,虽然整合时间在大多数的工作流程中并非瓶颈,但是在部分情况,特别是涉及文件重命名,整合会变得非常慢,而整合后端又被用于cherry-pick和rebase操作,这两个操作都会执行一系列整合,因此能加快整合速度,就能有效提升执行性能以及用户体验。

这个新的merge-ort是完全重写的政策,具有相同的递归和重命名侦测等概念,但是解决了长期存在的正确性和性能问题,执行速度比整合递归快上许多,在大型且复杂包含重命名的极端整合案例,merge-ort获得500倍的加速,而像是需要进行一系列整合的rebase操作,更是加速超过9,000倍。

这些极端案例对于整合递归政策特别不利,因此在merge-ort有很大幅度的加速,一般典型的整合情况,merge-ort只会比整合递归快一些,GitHub解释,merge-ort价值在于在各种情况都能维持整合性能,但是整合递归的性能却有极大的差异。

merge-ort另外一个优点,是生成的程序代码更清楚可用,其修复了整合递归部分已知的错误,不会访问树中未变更的部分,因此执行部分整合操作,Git不需要下载额外的对象,就能进行更多的整合工作,而且因为merge-ort在整合时,不依赖索引和工作树,因此git log等工具便能有机会发挥更大的作用,像是显示整合结果和最终提交状态的差异,借以呈现作者解决冲突的方法。

merge-ort很可能会成为未来Git版本的默认政策,开发者现在可以使用git merge -sort指令,或是将pull.twohead配置设置成ort,不过,GitHub提到,这样的更改并无法完全感受merge-ort带来的加速效果,因为还需要更改Git其他部分,但是仍可以先尝鲜。

发表评论