idea 實(shí)現(xiàn)git rebase操作詳解

本文結(jié)合idea工具進(jìn)行rebase的各種場景的操作，借助工具更能直觀地觀察到分支之間地操作差異，方便我們理解rebase的各種操作以及場景的使用。

1. git rebase介紹

rebase:翻譯成中文是重新設(shè)定，在這里可以理解為重新設(shè)置基線，也可以這么理解，將當(dāng)前分支重新設(shè)置起始點(diǎn)。
rebase會(huì)把你當(dāng)前分支的 commit 放到最后面,將rebase后的目標(biāo)分支的commit當(dāng)作基點(diǎn)放在前面，通俗的說就是將目標(biāo)分支的提交作為你當(dāng)前分支的基點(diǎn)，所以叫變基。

2. git rebase應(yīng)用

先準(zhǔn)備好一個(gè)主基線：

在此基礎(chǔ)上創(chuàng)建一個(gè)分支：名字為fenzhi_1，創(chuàng)建另一個(gè)分支，名字為fenzhi_2

最開始fenzhi_1和fenzhi_2以及master的基線是同一個(gè)。

2.1、 同一分支的rebase操作

當(dāng)前分支為fenzhi_2，共有三個(gè)提交記錄:

在第一次修改上進(jìn)行右擊鼠標(biāo)：選擇圖中的選項(xiàng)，翻譯一下就是在此處進(jìn)行交互式改變基址。
交互式可以理解為可自定義的選擇不同rebase行為進(jìn)行操作。

可以看到下面的界面，我們講解一下：紅色部分是操作欄，綠色部分是顯示的提交記錄，黃色部分是顯示選擇提交記錄的詳情信息，黑色部分就是執(zhí)行rebase操作或者取消

著重講解紅色部分：
Rebase的行為可以大致分為三類：
第一類：保留commit，不合并
1、pick: 標(biāo)記為pick的commit會(huì)在rebase操作后會(huì)直接保留下來，不做任何改動(dòng)，也不會(huì)合并，最上面的commit最好標(biāo)記為這一類
2、reword： 這一類commit也會(huì)保存下來，不過在保存下來之前會(huì)有一次修改commit message的機(jī)會(huì)
3、edit：這一類的commit也會(huì)直接保存下來，不過，當(dāng)合并到這種類型的commit時(shí)，整個(gè)合并經(jīng)常會(huì)暫停下來，你可以重新修改這次commit中的變動(dòng)內(nèi)容，比如給這個(gè)commit繼續(xù)新增一些代碼改動(dòng)、或者修改commit message，然后git add(不要忘記 git add了)， 再繼續(xù)使用git rebase —continue，來繼續(xù)rebase操作。
第二類：不保留commit，與上一次commit合并
1、squash：標(biāo)記為squash的commit在rebase操作完成后不會(huì)保留，它會(huì)與之相鄰的上一次commit進(jìn)行合并。同時(shí)它的commit message也會(huì)與上一次commit的message合并。
2、fixup: 這類commit不會(huì)保留，會(huì)直接與相鄰的上一次commit合并，與squash不同之處在于，它的commit message回直接丟棄，即這次commit會(huì)被視為對前一次commit的一次小的補(bǔ)充修改（fixup），commit message就以前一次為準(zhǔn)
第三類：不保留，直接刪除commit
1、drop：標(biāo)記為skip的commit會(huì)直接被刪除，就相當(dāng)于這次commit從來沒有發(fā)生過。同時(shí)，這個(gè)commit中涉及的所有代碼修改全部會(huì)被刪除。

值得注意的是：
不能全部選擇 drop commit，不然就沒有需要改變的了
squash 和 fixup 不能在第一個(gè)commit，因?yàn)樗麄冃枰c前一個(gè)commit配合

A、紅色的部分就是對提交記錄的操作，左邊的上下箭頭可以改變提交記錄的順序：
操作一下，選中第一次修改記錄然后點(diǎn)擊下箭頭：如圖所示可以第一次記錄跟第二次記錄的順序發(fā)生了變化

執(zhí)行rebase結(jié)果看一下：可以看到第一次提交記錄已經(jīng)在第二次修改上面了。（若其中有對同一個(gè)文件修改時(shí)，會(huì)出現(xiàn)沖突并處理完后，將同個(gè)文件所有的提交記錄折成一個(gè)）所以可以看出rebase操作其實(shí)也是有風(fēng)險(xiǎn)的，容易把別人的提交記錄刪除掉，在解決沖突時(shí)也就會(huì)出現(xiàn)替換別人的改動(dòng)。

B、第三個(gè)按鈕它顯示的提示是pick，其實(shí)它是對每個(gè)提交記錄的所有的操作恢復(fù)到最初的配置，記住不是所有提交記錄的操作回退，其實(shí)最初的操作就是默認(rèn)pick。
C、第四個(gè)是stop to edit，指的是不修改提交信息，點(diǎn)擊后：還是在第一次修改記錄中點(diǎn)擊這個(gè)按鈕，可以看到左邊顯示了按鈕。但雙擊鼠標(biāo)后可以解除此操作；

若修改第一次修改記錄，再點(diǎn)擊這個(gè)按鈕呢：

可以看到記錄給恢復(fù)原初的信息。

D、reword：通俗的說就是修改提交信息
E、Squash和Fixup是一組的，squash的操作會(huì)合并倆個(gè)提交的信息：如圖操作，也可以在選擇第二次操作后點(diǎn)上面的按鈕也可以的，這里是方便展示進(jìn)行的操作，點(diǎn)擊后我們看下結(jié)果：

可以看到第二次提交記錄合并到了第一次提交記錄上

執(zhí)行結(jié)果看一下：

要是點(diǎn)擊Fixup呢：可以看到若第二次合并到第一次后，提交記錄沿用第一次的提交記錄。

執(zhí)行結(jié)果看一下：
Rebase之前：可以看到倆次的提交記錄
 

Rebase之后，可以看到提交記錄合并到了一起。

F、drop：可以理解為丟棄，就是將刪除當(dāng)前提交的所有修改。將所有修改恢復(fù)到修改之前的樣子，并且刪除此次提交記錄。

執(zhí)行結(jié)果看一下：可以看到直接刪除了第二次的所有改動(dòng)記錄，也可以理解為回退了第二次的所有操作。

G、reset：這個(gè)操作就簡單了，就是還原對所有commit的操作
rebase操作后，又該如何push呢
比如我們執(zhí)行的是將第二次提交合并到第一次提交上：

可以看到有倆個(gè)操作提示：更新和推送。從操作來看，若rabase后不推送，執(zhí)行的是更新就會(huì)是遠(yuǎn)程的最新記錄替換本地的改變。但不能這么做，那rebase操作就白整了。我們得需要push

可以看到push有倆種選擇：若直接選擇的push，看下結(jié)果：

翻譯一下：push的時(shí)候它認(rèn)為你本地的變更與遠(yuǎn)程版本不一致

若選擇rebase的話，就會(huì)發(fā)現(xiàn)恢復(fù)到rebase操作之前的記錄
若選擇merge的話，可以看到處理的結(jié)果，原先的2條提交信息還在，只是會(huì)新生成一個(gè)整合后的提交。

看下面的記錄發(fā)現(xiàn)很奇怪。為啥第二次第三次提交成為了一個(gè)臨時(shí)提交，然后第三次提交又成為了第一次提交后的版本，然后第二次提交成為了新的一個(gè)提交記錄。
我們再次回到操作的時(shí)候：查看一下git的命令

可以看到第一次和第三次的行為是pick，而第二次的是fixup，所以進(jìn)行push時(shí)選擇的是merge時(shí)會(huì)出現(xiàn)上述的提交記錄。

如果自己分支的幾個(gè)提交都是本地的，還沒有提交到遠(yuǎn)程分支fenzhi_2上，那么就可以直接push推到遠(yuǎn)程,但一般我們總要合自己代碼到dev/test,所以必然是已經(jīng)提交到自己遠(yuǎn)程分支上了, 此時(shí)當(dāng)你去push你的commit時(shí)，會(huì)再次與你遠(yuǎn)程分支的commit合并，之前本地rebase的那些commit又會(huì)出現(xiàn)了。
若選擇force push呢，翻譯過來就是強(qiáng)制推送，看一下操作結(jié)果：有個(gè)提示，翻譯一下就是：強(qiáng)制推送，可能會(huì)覆蓋遠(yuǎn)程服務(wù)器的提交。

點(diǎn)擊強(qiáng)制推送

可以看到這個(gè)結(jié)果是想要的，但是這個(gè)也有不同的情況：
若這個(gè)遠(yuǎn)程分支只有你一個(gè)人在開發(fā)：強(qiáng)制推送是可以的，沒有人會(huì)在你rebase沒完成時(shí)提代碼，可以直接理解為用你本地分支的狀態(tài)區(qū)覆蓋掉遠(yuǎn)端origin分支的狀態(tài)，也就是執(zhí)行過后，本地的分支什么樣，遠(yuǎn)端分支就什么樣

2.2、分支跟master之間的rebase操作

Rebase的本意是改變基線，意思就是當(dāng)從master拉取的分支1開發(fā)一段時(shí)間后，master也提交了幾個(gè)版本，這就使得分支1的基線與現(xiàn)在的master不是同一個(gè)版本。需要將分支1的基線改成最新master。那就需要rebase操作了。看案例效果：
看一下fenzhi_2的基線是在提交id為1639f5db的基礎(chǔ)上拉的分支，然后做了倆次變更

再看一下master的提交記錄：master在 1639f5db上提交了一次變更。

這就造成了fenzhi_2的基線不是最新的master了，現(xiàn)在要將fenzhi_2的基線改為提交id為f7ec72e7，看下面操作
本地分支改為fenzhi_2：

在master上右擊鼠標(biāo)：第二步操作翻譯一下就是在master基礎(chǔ)上改變fenzhi_2的基線。

點(diǎn)擊操作：若看到有沖突，手動(dòng)處理一下即可，

可以看到同一個(gè)位置都有改動(dòng)，這就根據(jù)實(shí)際情況合并代碼了，這里我的目的是master的改動(dòng)和本分支的改動(dòng)都要保留。

解決完后，會(huì)自動(dòng)彈出一個(gè)窗口：是提交信息的修改，這個(gè)也是根據(jù)實(shí)際情況定，這里我不改，點(diǎn)擊繼續(xù)rebase。

看結(jié)果：提交id為f7ec72e7的成為了fenzhi_2的基線。

我們再看一下上面解決沖突后的代碼變更記錄：
先看基線的變更是Test.java文件進(jìn)行了變更

分支第一次提交id為a6330cc0的也修改了這個(gè)Test.java。那我們上面rebase后，本次變更就得在基線的基礎(chǔ)上變更，那我們看看是不是

結(jié)果來看，是我們想要的。這個(gè)結(jié)果是上面解決沖突的結(jié)果。

接下來push：可以看到push有倆個(gè)操作，一個(gè)push一個(gè)是force push（強(qiáng)制推送）。

若分支是自己使用，那我們就強(qiáng)制推送。本地的分支提交記錄覆蓋遠(yuǎn)程的。
看一下遠(yuǎn)程倉庫記錄：

上面的操作是分支改變基線，那反過來操作呢，在master上rebase呢。
看一下分支fenzhi_3：這個(gè)分支做了倆次變更

Master也做了倆次變更

在master上進(jìn)行rebase onto fenzhi_3:

可以看到有個(gè)提示：

大概意思就是會(huì)對master的提交記錄進(jìn)行修改，看下執(zhí)行結(jié)果：

發(fā)現(xiàn)分支的提交記錄在master記錄之前，這個(gè)與merge操作是相反的。繼續(xù)操作push

可以看到上面提示，若點(diǎn)擊合并呢：可以看到分支的提交跟master在一條線上，但最上面又有一條合并記錄。

若點(diǎn)擊的是rebase呢：可以看到是將分支fenzhi_3的提交放在了最前面。這個(gè)操作就模擬了代碼merge，但提交記錄是一條線。這個(gè)才是我們的本意。

這個(gè)時(shí)候若繼續(xù)將fenzhi_3 merge到master時(shí)只會(huì)產(chǎn)生一個(gè)合并記錄：

2.3、不同分支之間的rebase操作

不同分支之間的rebase操作是一個(gè)分支合并另一個(gè)分支的變更。這種操作的應(yīng)用場景是啥呢？看下面案例：
比如有個(gè)fenzhi_2和fenzhi_3

比如fenzhi_2開發(fā)的時(shí)候需要fenzhi_3的代碼，并把fenzhi_3的提交信息合并到fenzhi_2上，后續(xù)代碼都將在fenzhi_2上繼續(xù)開發(fā)。那rebase操作就相當(dāng)于使用了cherry-pick操作。但是fenzhi_2和fenzhi_3的基線不一致的話。就要考慮cherry-pick操作了，后面會(huì)通過案例詳細(xì)說明。

2.3.1、 同基線不同分支的rebase操作

開始操作：
指定當(dāng)前分支是fenzhi_2,在fenzhi_3上右擊鼠標(biāo)選擇變基操作：

可以看到有代碼沖突，說明在將fenzhi_3的提交變更一次依次合并到本分支的時(shí)候，遇到了fenzhi_2在同一文件的變更記錄。這時(shí)候要慎重選擇了。我這里需要保留倆個(gè)分支的變更。解決完沖突后，繼續(xù)rebase即可

看下結(jié)果，可以看到，它是將fenzhi_3的變更記錄放在了fenzhi_2的前面，這跟cherry-pick是不一樣的。所以選擇合并不同分支代碼的時(shí)候就要想清楚了。

推送代碼即可：這里是強(qiáng)制推送。這里前提是必須保證fenzhi_2的最新提交記錄與遠(yuǎn)程倉庫一樣的，若不確定的話，還是不要進(jìn)行強(qiáng)制推送了。

2.3.2、不同基線不同分支的rebase操作

看下分支fenzhi_1的基線是1639f5db，并提交倆次變更

看下分支fenzhi_2的基線是b269d2a0，提交一次變更。

從上面可以看到fenzhi_2的基線比fenzhi_1的基線高一個(gè)版本，這就會(huì)有倆種rebase情況，fenzhi_1 rebase onto fenzhi_2 或者 fenzhi_2 rebase onto fenzhi_1。
1、先看一下fenzhi_1 rebase onto fenzhi_2，操作步驟跟上面的一樣，這里直接看結(jié)果：

看結(jié)果，這里不僅把fenzhi_2的提交合并，也會(huì)把master的新提交合并過來，這里很容易理解，因?yàn)閞ebase的操作就是從共同基線開始的。
2、看一下fenzhi_2 rebase onto fenzhi_1：可以看到有個(gè)提示

翻譯下：

若繼續(xù)rebase呢：看下結(jié)果，很明顯fenzhi2_的基線就變了。

2.4、總結(jié)

Rebase操作可實(shí)現(xiàn)的功能有：
1、 同分支的多次提交合并、提交順序改變，提交記錄修改；
2、 修改下游分支的基線，同步上游的變更，將下游分支基線修改為最新；
3、 實(shí)現(xiàn)分支代碼合并到主線上，類似于merge操作，但區(qū)別是提交路徑的不同；
4、 實(shí)現(xiàn)不同分支之間的代碼提交合并。
根據(jù)上面的操作就可以看到rebase的主要核心用途是下游分支與上游分支的基線同步、同分支的提交記錄合并或者提交信息的修改。其他的操作只有特殊情況下才可以使用。

到此這篇關(guān)于idea 實(shí)現(xiàn)git rebase操作詳解的文章就介紹到這了,更多相關(guān)idea git rebase操作內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！