Git rebase 是 Git 中最容易被誤解的命令之一。初學者經常以錯誤的方式使用此命令，弄亂他們的工作樹，或者未能發現 git rebase 和 merge 之間的區別。因此，在本文中，我將嘗試使用圖形表示詳細解釋 git-rebase 實際做什麼和不做什麼。本文是關於變基的討論，而不是關於如何變基的快速教程。
Git 存儲命令
什麼是變基？
從字面上看，rebase 意味著更改對象的基礎。 Git rebase 與 git branch 做同樣的事情——它改變了分支的基礎。
但是分支的基礎究竟是什麼，我們為什麼要這樣做呢?我們將在本文接下來的幾節中回答這些問題。
分支的基本原理是什麼？
分支的基礎是與父分支不同的提交。它也可以定義為與分支及其父分支相同的最新提交。這是一個快速可視化，可幫助您理解這一點。
功能 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：將功能分支重新定位到 master 後的提交圖。 請注意，這兩個提交具有相同（重複）的消息，但 SHA1 不同。所以這些是不同的提交。原始提交在提交圖中顯示為分離節點。你什麼時候使用 git rebase？
與 git merge 生成的凌亂圖不同，git rebase 僅用於生成乾淨的提交線性圖。所以這是兩者之間的權衡
- Git 合併允許您保留提交歷史記錄，但代價是額外的提交和復雜的提交圖
- Git rebase 保持提交的數量相同，但以抽象提交歷史為代價。
因此，任何可以合併的分支都可以重新定位，反之亦然，但不建議重新定位公共/共享分支。使用變基時，用戶應牢記保留歷史記錄和清理提交圖之間的權衡。
結論是
我們關於 git-rebase 的文章到此結束。 Visual git 使用 git 命令的圖形表示。 請繼續關注有關 git 和其他開源程序的更多文章。