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其他部分,但是仍可以先嚐鮮。


熱門新聞

Advertisement