Git Conflict：Conflict 不是 Git 壞掉，而是 Git 不知道你要保留哪個意圖

Learning outcomes

• 能解釋 branch / merge base / merge commit。
• 能讀 conflict markers。
• 能用 status/diff 驗證 resolution。
• 能區分 merge 與 rebase 對 history 的影響。

1. Branch Divergence

A---B---C main
           D---E feature

兩條 branch 從共同 ancestor 分開發展。

2. Conflict Marker

<<<<<<< HEAD
const port = 3000;
=======
const port = 8080;
>>>>>>> feature

這不是要你「選上面或下面」而已；你要理解兩邊意圖，可能需要產生第三種正確答案。

3. Resolution Flow

git status
# inspect files

# edit correct final content

git add file
git status

# continue merge/rebase

4. Merge vs Rebase

merge:
preserve branch topology

rebase:
replay commits on new base

Rebase 會重寫 commit identity；對已共享 history 要特別小心。

5. Resolution 後一定要 Test

Conflict marker 清掉不代表行為正確。兩邊各自正確的 code 合併後仍可能產生 semantic conflict。

6. Semantic Conflict：Git 沒報 Conflict，Code 仍可能壞

Git 只知道文字差異，不懂完整 business intent。兩條 branch 修改不同檔案時，Git 可能自動 merge 成功，但兩邊合起來的行為仍互相矛盾。

Branch A:
API response 改成
{ "course": ... }

Branch B:
Frontend 仍讀
data.title

Git:
merge clean

Runtime:
UI breaks

所以「沒有 conflict marker」不代表 integration 一定正確。Merge 後仍要跑 tests、build、smoke，尤其是跨模組 contract。

7. Conflict Resolution 也要保留 History Intent

解 conflict 時先看兩邊 commit/message/diff，理解各自為何修改。若只把 marker 消掉卻刪掉其中一邊的重要 validation，Git 會接受，但功能已退化。

Project checkpoint：Course API Conflict

main:
PORT from env

feature:
hardcoded PORT 8080

Correct resolution:
keep env-driven config
plus feature's unrelated route

真正答案是合併意圖，不是選一邊整份檔案。

Debug evidence

先看 git status 知道目前正在 merge 還是 rebase；不要看到 conflict 就隨便 reset --hard 丟掉工作。