在前一篇我們介紹了 git merge，它能把兩個分支的工作合併在一起，保留完整的開發脈絡。但有些人會覺得這樣的歷史太「分叉」，看起來亂糟糟的。

這時候就輪到 git rebase 出場了！

git rebase 是什麼？

把你所在分支的 commit，重新「嫁接」到另一個分支上，就像是 時光機，把分支的起點移動到最新的基底。

• 如果 merge 是「分支交會再匯流」
• 那 rebase 就是「直接改寫歷史，好像你一開始就是在最新的基底上開發」

基本操作流程

假設目前分支狀態如下：

A---B---C (main)
     \
      D---E (feature)

切換到你的功能分支：

git switch feature

把它 rebase 到 main：

git rebase main

執行後結果會變成：

A---B---C (main)
            \
             D---E (feature)

這表示 feature 分支的 commit 現在「基於」 main 的最新版本。

rebase 與 merge 的比較

• merge：保留完整歷史，分叉清楚 → 適合團隊協作
• rebase：歷史線乾淨、直線 → 適合個人整理 commit

小提醒：rebase 會改寫 commit ID，不要在公開分支上使用，以免影響其他人歷史。

衝突處理

如果 rebase 過程中遇到衝突：

1. 編輯檔案，解決衝突

2. 將檔案加入暫存區：

   git add <檔案>
   

3. 繼續 rebase：

   git rebase --continue
   

若想放棄 rebase，回到原本狀態：

git rebase --abort

常見錯誤

• 在公開分支上使用 rebase

  → 會改寫 commit ID，造成團隊成員歷史不一致，容易混亂

• 忘記解決衝突就繼續 rebase

  → rebase 會中斷，必須先解決衝突

• 誤用 git rebase main 在錯誤分支

  → commit 會被重新套用到不想要的基底，造成歷史亂掉

• 以為 rebase 會自動更新遠端分支

  → rebase 只改本地分支，完成後要用 git push --force（小心！）

小挑戰 💪

1. 建立功能分支 feature，並各自 commit 幾個檔案
2. 在 main 上新增 commit
3. 嘗試 git rebase main，觀察歷史變化（git log --graph --oneline）
4. 再用 git merge main 做一次，對比差異
5. 思考：團隊合作時，你會偏好哪種方式？為什麼？

小結

• git rebase 可將分支基底移動到最新進度。
• 讓歷史更簡潔，但會改寫 commit ID。
• 適合個人開發時整理 commit，不建議在共享分支使用。