【新手救星】從有向無環圖 (DAG) 看版本控制：Git Rebase 與衝突處理的架構師指南

許多初階工程師視 Git 為畏途，擔心覆蓋他人程式碼。本文將從軟體架構與圖論（Graph Theory）的角度解析 Git 的運作原理。我們將探討如何透過 Rebase 維持線性的提交歷史（Linear History），以及如何以演算法的邏輯精準解決 Merge Conflict。掌握底層邏輯，你將不再死記指令，而是操作數據結構。

身為一名在分散式系統領域打滾多年的架構師，我常對學生說：「Git 不僅僅是一個版本控制工具，它是一個內容定址的檔案系統（Content-Addressable Filesystem），更是一個優雅的有向無環圖（Directed Acyclic Graph, DAG）。」

很多剛入行的工程師對 git push --force 感到恐懼，或者在遇到 Conflict 時手足無措，往往是因為他們只把 Git 當作備份工具，而沒有理解其背後的數學模型。今天，我們不談生硬的指令背誦，而是從「資料結構」的視角，手把手教你如何優雅地處理分支與衝突。

1. 為什麼我們要 Rebase？（拓撲結構的選擇）

在軟體工程中，可維護性（Maintainability）與程式碼品質同等重要。

當你使用 git merge 時，Git 會建立一個新的「合併提交（Merge Commit）」，這在圖論上創造了一個菱形迴圈。如果團隊中有 20 人同時開發，你的 Git Log 將會變成一團難以追蹤的「義大利麵（Spaghetti Graph）」。

git rebase（變基）的操作，本質上是「重寫歷史」。它將你當前分支上的所有 Commit 暫存起來，將分支的起點（Base）移動到目標分支的最新 Commit 上，然後依序重播（Replay）你的變更。

這帶來了兩個架構上的優勢：

線性歷史（Linear History）：Git Log 變成一條直線，除錯時使用 git bisect（二分搜尋法找 Bug）將變得極為高效。
原子性（Atomicity）：你的功能開發過程被整合成一組連續的邏輯單元，便於 Code Review。

2. 手把手 Rebase 實戰

假設你在 feature-login 分支，主分支是 main。

步驟一：更新本地知識庫永遠先確保你的本地端 main 是最新的。

git checkout main
git pull origin main

步驟二：執行變基切換回你的分支並執行 Rebase。

git checkout feature-login
git rebase main

此時，Git 會嘗試將你的 Commit 拆解成 Patch，並應用在最新的 main 之上。

3. 直面衝突：三路合併演算法（Three-way Merge）

當 Git 告訴你出現 CONFLICT 時，不要驚慌。這在分散式系統中是必然的現象——這是CAP 定理中分區容錯性（Partition Tolerance）的一種體現。兩個不同的處理程序（你和你的同事）同時修改了同一份數據的同一個狀態。

Git 採用的是三路合併演算法。它會比較：

Base（共同祖先）
Yours（你的變更）
Theirs（傳入的變更）

當你打開衝突檔案，你會看到：

<<<<<<< HEAD
const MAX_RETRIES = 5;  // 同事改成了 5
=======
const MAX_RETRIES = 10; // 你改成了 10
>>>>>>> feature-login

解決策略：這不是選 A 或選 B 的選擇題，而是邏輯題。你需要判斷：為什麼同事改成 5？為什麼你需要 10？

如果這是硬體限制，也許 5 是正確的。
如果這是為了測試吞吐量，也許 10 是必要的。
或者，正確答案是 config.MAX_RETRIES（重構）。

修改完畢後：

git add .
git rebase --continue

4. 安全網：Reflog

許多人不敢 Rebase 是怕「把程式碼弄丟」。作為架構師，我要告訴你 Git 最強大的安全網：reflog（Reference Logs）。

Git 幾乎不真正刪除數據。即便你 Rebase 失敗、Reset 錯誤，只要輸入 git reflog，你可以看到所有 HEAD 指標曾經停留過的位置。你隨時可以用 git reset --hard HEAD@{n} 回到過去。在計算機科學中，這提供了極高的容錯性（Fault Tolerance）。