【Git 協同篇】三方合併（Three-Way Merge）揭秘：Git 到底如何尋找共同祖先（Merge Base）與判定每一行衝突？ / [Git Three-Way Merge Internals] How Git Finds the Merge Base and Determines Line-by-Line Conflicts
在多名工程師協同開發大型系統時，「合併代碼」幾乎是每天都會執行的核心動作。當你在終端機下達 git merge feature ，看到終端機回傳「Merge made by the 'ort' strategy.」並且幾十個檔案順暢無阻地合為一體時，你是否曾好奇：Git 究竟是憑藉什麼魔法，能精準知道哪一行是誰新增的、哪一行是誰刪除的？又是依據什麼規則，在雙方改動重疊時精準拋出衝突？ When multiple engineers collaborate on large-scale systems, merging branches is an indispensable daily routine. When you run git merge feature and watch the console announce "Merge made by the 'ort' strategy" while dozens of files seamlessly combine, have you ever wondered: What mathematical mechanics allow Git to discern exactly who added or removed each line? By what underlying rules does it flag conflicts when edits overlap? 承接我們上一篇深入探討的 Git Rebase 補丁重播與雜湊移植機制，今天我們將焦點轉向分支整合的另一大基石——「三方合併」（Three-Way Merge）。許多開發者以為合併只是把兩個分支的最新快照拿來互相比對，然而單純的「雙方比對」在數學邏輯上根本無法判定檔案到底是新增還是刪除。要解開這個謎題，必須深入探究 Git 如何在有向無環圖中尋找「共同祖先」（Merge Base），以及 Diff3 演算法如何在每一行代碼中進行裁決。 Continuing our previous deep dive into Git Rebase patch replay and hash recomputation, today we pivot to the other fou...
