Merge Or Rebase

爱新觉罗LQ發表於2024-05-05

Merge Or Rebase

都具備分支間變更的能力：但是二者間實現手段大不相同

1. 實現手段

Merge（總是向前推進提交歷史，並不會影響提交的原始狀態）

我們在特性分支上，執行

# git 會以 我方、對方、以及雙方最近公共祖先 對應的快照 ===> 執行三路合併生成新的快照
git merge master


三路合併生成新的快照

並基於此快照，建立一個連線 特性分支 feature 和 主幹的合併節點

最後調整特性分支的指向

Rebase（整合變更，對提交歷史進行重寫）

我們在特性分支上，執行

# 1. git 會從雙方最近的公共祖先開始，將特性分支每個提交對應的變更暫存起來，
# 2. 然後以主幹分支指向的提交 為新起點，將暫存的變更按順序，一一 還原成新提交
git rebase master
  1. git 會從雙方最近的公共祖先開始，將特性分支每個提交對應的變更暫存起來，
  2. 然後以主幹分支指向的提交 為新起點，將暫存的變更按順序，一一 還原成新提交

    此時，特性分支的新起點，就像是從 C1 遷移到了 C6

2. 異同點

同

內容完全一致

異

二者卻構建出了迥異的提交的歷史

3. 日常開發中經常遇到的例子【開發者從 feature 發起 PR】

由於 master 分支也合入了新的提交，在 PR 中顯示，feature 分支和主幹間存在衝突而無法合併，此時開發者通常有2 種方式解決衝突問題

將 master 分支 merge 到 feature 分支，並在合併時解決衝突

這樣做會在方法方法會在 feature 分支中引入一個合併提交（包含解決衝突所做的修改）

將 feature 分支 rebase 到 master 的最新提交，並在 rebase 過程中解決衝突

4. 互動式 Rebase【提交的重排、壓縮、拆分、丟棄】

git rebase -i master

順序調整

squash 命令（實現對提交的壓縮）

drop 指令

5. rebase -i 綜合應用

6. 注意點

Git rebase 在重設基線，修整歷史的過程中，會產生新的提交替換老提交，謹記：
千萬不要使用 rebase 處理已經被其它協作者引用的提交

相關文章