本文用最簡潔的例子讓你快速掌握rebase原理和用法

一、提交節點圖解
首先通過簡單的提交節點圖解感受一下rebase在幹什麼

兩個分支master和feature，其中feature是在提交點B處從master上拉出的分支

master上有一個新提交M，feature上有兩個新提交C和D

此時切換到feature分支上，執行如下命令，相當於是想要把master分支合併到feature分支

git checkout feature
git rebase master

//這兩條命令等價於git rebase master feature

下圖為變基後的提交節點圖，解釋一下其工作原理：

feature：待變基分支、當前分支
master：基分支、目標分支
官方解釋：當執行rebase操作時，git會從兩個分支的共同祖先開始提取待變基分支上的修改，然後將待變基分支指向基分支的最新提交，最後將剛才提取的修改應用到基分支的最新提交的後面。

結合例子解釋：當在feature分支上執行git rebase master時，git會從master和featuer的共同祖先B開始提取feature分支上的修改，也就是C和D兩個提交，先提取到。然後將feature分支指向master分支的最新提交上，也就是M。最後把提取的C和D接到M後面，但這個過程是刪除原來的C和D，生成新的C’和D’，他們的提交內容一樣，但commit id不同。feature自然最後也是指向D’。

通俗解釋（重要！）：rebase，變基，可以直接理解為改變基底。feature分支是基於master分支的B拉出來的分支，feature的基底是B。而master在B之後有新的提交，就相當於此時要用master上新的提交來作為feature分支的新基底。實際操作為把B之後feature的提交存下來，然後刪掉原來這些提交，再找到master的最新提交位置，把存下來的提交再接上去（新節點新commit id），如此feature分支的基底就相當於變成了M而不是原來的B了。

二、實際git提交示例
按照上面的圖解構造了提交記錄，如下圖所示：（ABM是master分支線，ABCD是feature分支線。這裡畫成了master變色分叉出來，這不影響理解，知道是表示兩個分支兩條線即可！）

此時，在feature分支上執行git rebase master

變基完成以後，ABCD是原來的feature分支線，ABMC’D’是新的feature分支線，ABM是master分支線（沒有變化）

三、推薦使用場景
搞來搞去那麼多，這其實是最重要的。不同公司，不同情況有不同使用場景，不過大部分情況推薦如下：

拉公共分支最新程式碼的時候使用rebase，也就是git pull -r或git pull --rebase，但有個缺點就是rebase以後我就不知道我的當前分支最早是從哪個分支拉出來的了，因為基底變了嘛。（如果使用merge，多出無意義的一條提交記錄“Merge … to …”）
往公共分支上合程式碼的時候，使用merge。（如果使用rebase，那麼其他開發人員想看主分支的歷史，就不是原來的歷史了，歷史已經被你篡改了）
參考文章：圖解 Git 基本命令 merge 和 rebase

其中還有一句解釋也很直白，rebase 命令其實關鍵在於理解「基」，git rebase <基分支>，就是將基分支與當前分支的差異提交（分岔點之後）獲取到，然後在「基分支」最新提交點後面將差異提交逐個再次提交，最後將當前分支的 HEAD 指標指向最新的提交點
————————————————
版權宣告：本文為CSDN博主「風中一匹狼v」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/weixin_42310154/article/details/119004977