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其他部分，但是仍可以先尝鲜。