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

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

1. git rebase介紹

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

2. git rebase應用

先準備好一個主基線：

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

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

2.1、 同一分支的rebase操作

當前分支為fenzhi_2，共有三個提交記錄:

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

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

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

值得注意的是：
不能全部選擇 drop commit，不然就沒有需要改變的了
squash 和 fixup 不能在第一個commit，因為他們需要與前一個commit配合

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

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

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

若修改第一次修改記錄，再點擊這個按鈕呢：

可以看到記錄給恢復原初的信息。

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

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

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

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

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

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

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

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

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

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

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

翻譯一下：push的時候它認為你本地的變更與遠程版本不一致

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

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

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

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

點擊強制推送

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

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

Rebase的本意是改變基線，意思就是當從master拉取的分支1開發(fā)一段時間后，master也提交了幾個版本，這就使得分支1的基線與現(xiàn)在的master不是同一個版本。需要將分支1的基線改成最新master。那就需要rebase操作了?？窗咐Ч?br />看一下fenzhi_2的基線是在提交id為1639f5db的基礎上拉的分支，然后做了倆次變更

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

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

在master上右擊鼠標：第二步操作翻譯一下就是在master基礎上改變fenzhi_2的基線。

點擊操作：若看到有沖突，手動處理一下即可，

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

解決完后，會自動彈出一個窗口：是提交信息的修改，這個也是根據(jù)實際情況定，這里我不改，點擊繼續(xù)rebase。

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

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

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

結果來看，是我們想要的。這個結果是上面解決沖突的結果。

接下來push：可以看到push有倆個操作，一個push一個是force push（強制推送）。

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

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

Master也做了倆次變更

在master上進行rebase onto fenzhi_3:

可以看到有個提示：

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

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

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

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

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

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

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

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

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

開始操作：
指定當前分支是fenzhi_2,在fenzhi_3上右擊鼠標選擇變基操作：

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

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

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

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

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

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

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

看結果，這里不僅把fenzhi_2的提交合并，也會把master的新提交合并過來，這里很容易理解，因為rebase的操作就是從共同基線開始的。
2、看一下fenzhi_2 rebase onto fenzhi_1：可以看到有個提示

翻譯下：

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

2.4、總結

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

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

最新評論