在這個例子中，你可以檢出 experiment 分支，然後將它變基到 master 分支上：
它的原理是首先找到這兩個分支（即當前分支 experiment、變基操作的目標基底分支 master） 的最近共同祖先 c2，然後對比當前分支相對於該祖先的歷次提交，提取相應的修改並存為臨時檔案， 然後將當前分支指向目標基底 c3, 最後以此將之前另存為臨時檔案的修改依序應用。 （譯註：寫明了 commit id，以便理解，下同）
現在回到 master 分支，進行一次快進合併。
此時，c4』 指向的快照就和 the merge example 中 c5 指向的快照一模一樣了。 這兩種整合方法的最終結果沒有任何區別，但是變基使得提交歷史更加整潔。 你在檢視乙個經過變基的分支的歷史記錄時會發現，儘管實際的開發工作是並行的， 但它們看上去就像是序列的一樣，提交歷史是一條直線沒有分叉。
一般我們這樣做的目的是為了確保在向遠端分支推送時能保持提交歷史的整潔——例如向某個其他人維護的專案貢獻**時。 在這種情況下，你首先在自己的分支裡進行開發，當開發完成時你需要先將你的**變基到 origin/master 上，然後再向主專案提交修改。 這樣的話，該項目的維護者就不再需要進行整合工作，只需要快進合併便可。
請注意，無論是通過變基，還是通過三方合併，整合的最終結果所指向的快照始終是一樣的，只不過提交歷史不同罷了。 變基是將一系列提交按照原有次序依次應用到另一分支上，而合併是把最終結果合在一起。
更有趣的變基例子
$ git rebase --onto master server client
現在可以快進合併 master 分支了。
接下來你決定將 server 分支中的修改也整合進來。
至此，client 和 server 分支中的修改都已經整合到主分支裡了， 你可以刪除這兩個分支，最終提交歷史會變成圖 最終的提交歷史 中的樣子：
變基的風險呃，奇妙的變基也並非完美無缺，要用它得遵守一條準則：
如果提交存在於你的倉庫之外，而別人可能基於這些提交進行開發，那麼不要執行變基。
如果你已經將提交推送至某個倉庫，而其他人也已經從該倉庫拉取提交並進行了後續工作，此時，如果你用 git rebase 命令重新整理了提交並再次推送，你的同伴因此將不得不再次將他們手頭的工作與你的提交進行整合，如果接下來你還要拉取並整合他們修改過的提交，事情就會變得一團糟。
對git的rebase（變基）的理解
其實git的官網對變基的解析挺詳細的了 位址 從原理上也能理解 變基 和 合併 有啥區別。我的理解是，變基 和 合併 都能解決乙個問題，那就是合併 但是他們的區別是 在master的記錄上會有所不同。如下圖 我是用sourcetree做的合併與變基的 合併 變基 從上面那兩個圖可以看到，如果是 合併...
5 Git的分支管理
git的分支管理是讓很多開發者來跟蹤自己的專案的原因之一。當你提交的時候，git都會把檔案串成一條時間線，這條時間線就是乙個分支，也是最重要的分支，我們叫做master 主分支 head嚴格來說，並不是指向提交的，而是指向master的，master才是指向提交的。一開始的時候，master分支是一...
git提取和拉取區別 Git基礎知識 八 變基
變基圖示 變基 在 git 中整合來自不同分支的修改主要有兩種方法 merge 從master分支的c2提交拉取分支experiment並建立c4提交 從c2建立c3提交 將experiment分支合入master，master前進至c5 merge rebase 將上例中的c4的修改直接基於c3進...