Git Merge 與 Git Rebase 的差異與應用

自己的分支用 rebase，公共的分支用 merge。記住這句話就好。

先講結論

Merge 保留分支歷史，適合公共分支；Rebase 讓歷史變乾淨，適合私有分支。不確定用哪個？用 merge，比較安全。在繼續之前，確保你熟悉 基本指令 和 進階指令。

先看圖就懂了

gitGraph
    commit id: "A"
    commit id: "B"
    branch feature
    commit id: "C"
    commit id: "D"
    checkout main
    commit id: "E"
    merge feature id: "Merge commit"

上面是 Merge — 分支的分叉和合併點都清楚保留著。

Rebase 則會把提交歷史「攤平」成一條直線。Rebase 之後，看起來就像你從來沒開過分支一樣。乾淨俐落，但你失去了分支的歷史記錄。

什麼時候用哪個？

用 Merge 的時候：在公共分支上合併、分支間差異大、你想保留完整歷史。

用 Rebase 的時候：在自己的功能分支上整合最新的 main、你想讓提交歷史更乾淨、合併前整理 commit。

操作比較

# Merge：切到 main，把 feature 合進來
git checkout main
git merge feature-branch
 
# Rebase：切到 feature，把 main 的最新變更接在下面
git checkout feature-branch
git rebase main
# 然後切回 main 做 fast-forward merge
git checkout main
git merge feature-branch

Rebase 的黃金守則

永遠不要在公共分支上 rebase。 為什麼？因為 rebase 會重寫 commit history，所有 commit 的 hash 都會改變。如果別人也在用這個分支，他們的本地歷史跟遠端就對不上了，接下來就是一場災難。

Rebase 衝突的處理方式：

# 手動解決衝突後
git add <file>
git rebase --continue

我的實戰建議

1. 個人分支：rebase 到最新的 main 再發 PR，讓 reviewer 看到乾淨的歷史
2. 合併 PR 時：用 merge（或 squash merge），保留合併點
3. 不確定：用 merge，比較安全
4. 團隊要有共識：不管選哪個，大家要用同一套規則

---

Merge 和 Rebase 的爭論大概跟 tabs vs spaces 一樣永無止境。但至少現在你知道差別了，可以有立場地參與這場聖戰。接下來看看 Git Flow 了解完整的分支管理策略。

---

參考資源

• Git Merge 官方文件
• Git Rebase 官方文件

延伸閱讀

• Git 基本指令 — 先打好基礎
• 進階 Git 指令 — 更多進階操作
• Git Flow — 完整的分支管理模型
• GitHub Flow — 簡潔的分支管理策略
• Release 管理 — 版本發佈流程