Git rebase 是 Git 中最容易被誤解的命令之一。初學者經常不能用錯誤的方式使用這個命令來破壞工作樹或者找到 git rebase 和 merge 的區別。這就是為什麼本文使用圖形表示來詳細說明 git-rebase 中實際發生的事情和沒有發生的事情。本文是對 rebase 的解釋，而不是關於如何 rebase 的簡單教程。
Git 存儲命令
什麼是變基？
從字面上看，變基意味著改變對象的基礎。 Git rebase 和 git 分支做同樣的事情——改變一個分支的基礎。
但究竟什麼是分支的基礎，你為什麼要這樣做？這些問題將在本文接下來的幾節中得到解答。
分支的依據是什麼？
分支的基礎是從父分支分支出來的提交。您還可以將其定義為與分支及其父分支相同的最新提交。這是一個簡單的可視化來理解它。
功能 1 是其功能分支偏離主分支的提交。所以這是功能分支的基本提交。
使用 git rebase，我有興趣將此基礎更改為另一個提交。也就是說，功能 2 中的提交是指另一個提交，而不是功能 1。
git rebase 是做什麼的？
在深入了解該命令的詳細信息之前，讓我們快速了解一下 git 命令的語法。
git rebase <target branch>
此命令將當前分支重新定位到目標分支。這意味著當前分支基於目標分支的最後一次提交。因此， git commit-graph 使它看起來像是基於當前基礎的提交，因為該分支從未與原始分支分離。這使得提交圖看起來是線性的。
命令語法不是最重要的部分，重要的部分是命令的功能。 破壞 git rebase 將導致不需要的提交和復雜的提交圖，而不是所需的線性乾淨提交圖。讓我們仔細看看 git rebase。
如文章開頭所述，Git rebase 更改了分支的基礎。然而，這條線只是部分正確。
這些是您對 git rebase 的期望
- 將分支基礎更改為目標分支上的最新提交。
- 不要更改當前分支的提交。
如果 git rebase 遵循這個原則，命令後的圖 1 中的 git commit 圖 git rebase master 如下。
但是這裡沒有小問題。
- 遵循上述方法基本上會丟棄對該分支的提交歷史。 刪除或重寫 git 歷史的命令可能是問題的潛在來源。
- 如果功能分支的提交日期早於目標分支的新提交，則 rebase 分支的新提交（相對於時間）將比基本提交更早，從而產生絕對悖論。
為了解決這些問題， git rebase 實際上做的是：
- 將分支頭指針重定位到目標分支指針。 （功能現在指向主人）
- 在分支上進行新的重複提交。這些提交與原始提交具有基本相同的代碼更改，但具有不同的 SHA1 值。
- 舊提交以分離狀態顯示在圖表中。
現在讓我們最終想像一下真正的 git-rebase 會發生什麼。
圖 3：在主節點上重新構建功能分支後的提交圖。 請注意，兩次提交的消息相同（重複），但 SHA1 不同。也就是說，提交是不同的。原始提交在提交圖中顯示為分離節點。你什麼時候使用 git rebase？
與 git merge 創建的雜亂圖不同，Git rebase 僅旨在創建一個乾淨的提交線性圖。所以這是兩者之間的權衡。
- Git 合併允許你保留你的提交歷史，但代價是額外的提交和復雜的提交圖。
- Git rebase 保持提交的數量相同，但以抽象提交歷史為代價。
因此，您可以對所有可以合併的分支進行變基，反之亦然，但我們不建議對公共/共享分支進行變基。使用 rebase 時，用戶應牢記保存歷史記錄和乾淨的提交圖之間的權衡。
結論是
關於 git-rebase 的文章到此結束。 Visual git 使用 git 命令的圖形表示。 請繼續關注有關 git 和其他開源程序的此類文章。