1.變基的基本操作

　　在Git中整合來自不同分支的修改主要有兩種方法：merge和rebase。

看下面的例子：?開發(fā)任務分叉到了兩個不同的分支，并且都有了新的提交。

這時候我們可以使用?git merge?命令將experiment分支合并進入master分支，Git會將C3、C4以及兩者最近的共同祖先做一個三方合并，并且生成一個新的提交。如下圖所示：

　　其實我們還可以使用rebase命令：rebase命令將提交到某一分支上的提交都移至另一個分支上

$ git checkout experiment $ git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command

　　如下圖所示：??使用rebase之后，將experiment分支上的提交移動到了master分支的后面。

　　原理：首先找到兩個分支（當前所在分支experiment和目標基底分支master）的最近共同祖先（即C2），然后對比當期分支相對于最近共同祖先的所有提交，提取相應的修改存為臨時文件，然后將當前分支指向目標基底（即C3），最后將此前存好的臨時文件依次應用（理解為將從當前分支上，從最近共同祖先開始的后一個提交節(jié)點，開始復制，放到目標基底后）。

　　完成rebase操作之后，可以運行以下命令，進行一次快速移動。

$ git checkout master $ git merge experiment

　　操作完成之后，提交歷史如下圖所示。

　　與直接使用merge命令相比，rebase命令可以使提交歷史更加的整潔，看上去就像是一條直線。使用rebase的目的是是提交歷史看起來更加的整潔，其實，無論是通過merge還是rebase，整合的最終結(jié)果都是一樣的，只不過rebase的提交歷史看起來更加的整潔。rebase是將一系列提交按照原有次序依次應用到另一分支上，而merge是將最終結(jié)果merge在一起。

2.rebase VS merge?

　　對于rebase和merge哪種好，有兩種觀點：

　　1.有一種觀點認為，倉庫的提交歷史即是記錄著實際上發(fā)生過什么，它是一種歷史文檔，本身具有價值，不能隨意修改，這些歷史應該被保留下來，供后人進行查閱。這種觀點支持使用merge而不是rebase。

　　2.另一種觀點正好相反，他們認為提交歷史是項目開發(fā)過程中發(fā)生的事情，沒有人會出版一本書的第一版草稿，都是需要進行多次修訂之后才能進行出版的，修訂之前的這些歷史不應該被讀者看到。這種觀點鼓勵使用rebase。

　　總的原則：只對尚未推送或分享給他人的本地修改執(zhí)行rebase操作清理歷史，從不對已經(jīng)提交到別處的提交進行rebase操作。

?

轉(zhuǎn)載于:https://www.cnblogs.com/wangwenhui/p/10673294.html

總結(jié)

以上是生活随笔為你收集整理的13.Git分支-变基（rebase）、rebase VS merge的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。