Terry Yao's Blog

Git Merge 與 Git Rebase 的差異與應用

閱讀時間約 9 分鐘

cover

Git Merge 與 Git Rebase 的差異與應用

這大概是 Git 裡面最常被問到的問題之一：「到底要用 merge 還是 rebase？」如果你也有這個疑問，那這篇文章就是為你寫的。

在繼續之前，確保你已經熟悉 Git 基本指令 和 進階 Git 指令，這樣讀起來會更順。

文章概覽

在本篇文章中，你會學到：

  • Git Merge 與 Git Rebase 的基本概念
  • 各自的優缺點
  • 何時使用 Git Merge 何時使用 Git Rebase
  • 實際操作示例
  • 對團隊協作的影響

Git Merge 與 Git Rebase 的視覺比較

先來看看兩者在視覺上的差別。這是理解 merge 和 rebase 最直覺的方式：

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"

上面是 Git Merge 的效果 — 你可以看到分支的分叉和合併點都清清楚楚地保留著。

而 Git Rebase 會把提交歷史「攤平」成一條直線。Rebase 之後，看起來就像是你從來沒有開過分支一樣。乾淨俐落，對吧？但這也意味著你失去了分支的歷史記錄。

Git Merge 與 Git Rebase 的基本概念

Git Merge

  • 定義：將兩個分支的歷史合併到一起，保留各自的提交歷史。
  • 作用：保持分支的歷史記錄，顯示合併點。

Git Rebase

  • 定義：將一個分支的基礎更改為另一個分支的最新提交，形成更線性的提交歷史。
  • 作用：重寫提交歷史，避免分支的合併提交，使歷史更簡潔。

優缺點分析

分析 Git Merge

  • 優點：
    • 保留完整的分支歷史，清楚顯示合併點。
    • 不會重寫歷史，對公共分支更安全。
  • 缺點：
    • 可能導致提交歷史變得雜亂，有許多合併提交。
    • 對於大型專案，合併衝突可能較多。

分析 Git Rebase

  • 優點：
    • 生成更簡潔、線性的提交歷史，易於閱讀和理解。
    • 避免不必要的合併提交，使歷史更乾淨。
  • 缺點：
    • 會重寫提交歷史，對於公共分支可能導致問題。
    • 使用不當可能丟失提交或引入錯誤。

應用場景

何時使用 Git Merge

  • 當你希望保留分支的完整歷史記錄時。
  • 在公共分支上進行合併，避免歷史重寫帶來的問題。
  • 當分支之間的差異較大且合併衝突可能較多時。

何時使用 Git Rebase

  • 當你希望保持提交歷史的線性和簡潔時。
  • 在私有分支上進行變基操作，確保不影響其他團隊成員。
  • 當你需要整合最新的主分支變更到功能分支時。

簡單的記憶法：自己的分支用 rebase，公共的分支用 merge。這樣就不會搞砸別人的東西了。

實際操作示例

操作 Git Merge

git checkout main
git merge feature-branch

操作 Git Rebase

git checkout feature-branch
git rebase main

實際案例

案例一：功能分支的合併

假設你有一個功能分支 feature-login，已經完成了用戶登入功能的開發。現在，你需要把它合併到 main 分支。

使用 Git Merge

  1. 切換到 main 分支：

    git checkout main

  2. 合併 feature-login 分支：

    git merge feature-login

  3. 這會在 main 分支上創建一個新的合併提交，保留所有提交歷史。

使用 Git Rebase

  1. 切換到 feature-login 分支：

    git checkout feature-login

  2. 變基到 main 分支：

    git rebase main

  3. 解決任何可能出現的衝突，然後完成變基。

  4. 切換回 main 分支並快進合併：

    git checkout main
git merge feature-login

  5. 這不會創建新的合併提交，提交歷史更加線性。

對團隊協作的影響

  • Git Merge：

    • 保留完整的歷史記錄，便於追蹤變更和合併點。
    • 更適合團隊協作中的公共分支，避免歷史重寫的風險。

  • Git Rebase：

    • 生成更乾淨的提交歷史，便於代碼審查和維護。
    • 在協作過程中使用需謹慎，避免對公共分支進行變基操作。

最佳實踐提示

  • 使用 Rebase 保持歷史清晰：在個人功能分支上使用 Rebase，可以保持提交歷史的線性和清晰。
  • 避免在公共分支上使用 Rebase：對於已經推送到遠端的分支，避免使用 Rebase，以防止影響其他協作者。這一點超級重要，切記切記！
  • 經常同步主分支：無論是使用 Merge 還是 Rebase，經常將主分支的變更同步到功能分支，有助於減少合併衝突。
  • 使用 Pull Request 進行代碼審查：在合併分支前，通過 Pull Request 進行代碼審查，確保代碼質量和一致性。

常見問題解答

問：如果在 Rebase 過程中遇到衝突，應該怎麼辦？

答：遇到衝突時，Git 會提示你哪些文件有衝突。手動編輯這些文件解決衝突後，用 git add 添加解決後的文件，然後繼續變基：

git add <file>
git rebase --continue

問：Rebase 會刪除分支的歷史記錄嗎？

答：Rebase 不會刪除歷史記錄，但會重寫提交歷史，使其看起來更線性。原有的提交會被新的提交取代（commit hash 會改變）。

問：什麼時候應該選擇 Merge，什麼時候應該選擇 Rebase？

答：如果你希望保留分支的完整歷史記錄，並且不介意有合併提交，選 Merge。若你希望提交歷史更線性，且主要在個人分支上工作，選 Rebase。不確定的話，就用 Merge 吧，比較安全。

總結

Git Merge 和 Git Rebase 各有優缺點，適用於不同的場景。理解它們的差異和應用場景，能幫你更有效地管理分支和版本控制。選擇合適的策略，不僅能提升開發效率，還能保持提交歷史的清晰和可讀性。

建議在團隊中制定明確的分支管理策略，根據專案需求選擇最適合的方法。想了解更多分支管理策略，可以繼續看看 Git Flow、GitHub Flow 和 GitLab Flow。

參考資源

延伸閱讀

關係圖譜

反向連結