Branch / Merge / Conflict：不是「兩份資料夾」，而是兩條 Commit History

Learning outcomes

• 能畫出 branch pointer 與 commit graph。
• 能區分 fast-forward、merge commit、conflict。
• 能安全解 conflict marker 並重新測試。
• 能理解「沒有 textual conflict」仍可能有 semantic conflict。

1. Branch 是 reference

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

feature 不是另一份完整 repository；它是指向 E 的 branch name，而 commits 共享祖先。

2. Merge 找共同祖先再整合差異

git switch main
git merge feature

若 main 沒有分叉，可能 fast-forward；若兩邊都有新 commits，Git 可能建立 merge commit。

3. Conflict marker 是未決策狀態

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

你的工作不是「刪 marker 就好」，而是理解兩邊 intent，寫出正確 final code，再 stage/commit。

4. 解完文字 conflict 還要驗 behavior

git status
npm run check:js
npm run check
npm run build

兩段各自正確的 code 合在一起也可能產生 semantic conflict，例如兩邊都新增同名 route、都修改 schema assumption。

5. Abort 是合法選項

git merge --abort

如果你還沒理解 conflict，不必硬解。先回到 merge 前狀態、蒐集更多 context，通常比亂選 ours/theirs 安全。

Project checkpoint：Course Workspace v4

建立 feature/course-search，讓 main 與 feature 都修改同一段設定。故意製造 conflict，畫出 commit graph、解決後跑完整 checks。

git switch -c feature/course-search
# commit feature change
git switch main
# commit competing change
git merge feature/course-search

Debug evidence：CI 在 merge 後才壞

如果 merge 本身無 conflict，但 CI fail，先比較 merge 前兩邊各自通過的 assumptions。這是 semantic integration failure，不要因為 Git 顯示 clean 就認為整合一定正確。