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

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

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

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

合并递回使得最佳化和扩充程式码变得困难，虽然合并时间在大多数的工作流程中并非瓶颈，但是在部分情况，特别是牵涉档案重新命名，合并会变得非常慢，而合并后端又被用于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其他部分，但是仍可以先尝鲜。