git merge 與 git rebase的區別

**:

其實這個問題困擾我有一段時間，相信也有人和我一樣有這個困擾，網上已有很多這種解釋了，但是要麼就是無圖，要麼就是解釋的很亂，沒太看懂，經過自己對git的使用，加上向同事請教，算是理解了這個問題，所以寫下來分享一下，我盡量詳細說明

merge與rebase的區別

假設我們有如下圖一所示倉庫，該倉庫有master和develop兩個分支，且develop是在（3.added merge.txt file）commit處從master拉出來的分支。

圖一merge

假設現在head在（6.added hello.txt file）處，也就是在master分支最近的一次提交處，此時執行git merge develop, 結果如下圖所示。

圖二工作原理就是：git 會自動根據兩個分支的共同祖先即 (3.added merge.txt file)這個 commit 和兩個分支的最新提交即 (6.added hello.txt file) 和 (5.added test.txt file) 進行乙個三方合併，然後將合併中修改的內容生成乙個新的 commit，即圖二的(7.merge branch 『develop』)。

這是merge的效果，簡單來說就合併兩個分支並生成乙個新的提交。

rebase

那rebase是這麼工作的呢？

假設初始狀態也是圖一所顯示的。兩個分支乙個master，乙個develop，此時head在（6.added hello.txt file）處，現在執行git rebase develop,結果如下圖三所示。

圖三可以看見develop分支分出來分叉不見了，下面來解釋一下它的工作原理：

在執行git rebase develop之前，head在（6.added hello.txt file）處，當執行rebase操作時，git 會從兩個分支的共同祖先 (3.added merge.txt file)開始提取當前分支（此時是master分支）上的修改，即（6.added hello.txt file）這個commit，再將 master 分支指向目標分支的最新提交（此時是develop分支）即（5.added test.txt file）處，然後將剛剛提取的修改應用到這個最新提交後面。如果提取的修改有多個，那git將依次應用到最新的提交後面，如下兩圖所示，圖四為初始狀態，圖五為執行rebase後的狀態。

圖四

圖五簡單來說，git rebase提取操作有點像git cherry-pick一樣，執行rebase後依次將當前的提交cherry-pick到目標分支上，然後將在原始分支上的已提取的commit刪除。

merge or rebase

那什麼時候用merge，什麼時候用rebase呢？

再舉個例子：

初始狀態如下圖六所示：

和之前一樣的是，develop分支也是在 (3.added merge.txt file)處從master分支拉取develop分支。不一樣的是兩個分支各個commit的時間不同，之前develop分支的4和5commit在master分支3之後6之前，現在是develop分支的4提交早於master分支的5提交，develop分支的6提交晚於master的5提交早於master的7提交。

圖六在上圖情況下，在master分支的7commit處，執行git merge develop，結果如下圖七所示：

圖七執行git rebase develop，結果如下圖八所示：

圖八1. 可以看出merge結果能夠體現出時間線，但是rebase會打亂時間線。

2. 而rebase看起來簡潔，但是merge看起來不太簡潔。

3. 最終結果是都把**合起來了，所以具體怎麼使用這兩個命令看專案需要。

還有一點說明的是，在專案中經常使用git pull來拉取**，git pull相當於是git fetch + git merge，如果此時執行git pull -r，也就是git pull –rebase，相當於git fetch + git rebase

最後推薦一些git視覺化工具，我用的是gitkraken，這些工具功能基本一樣，看個人喜歡好使用

鳴謝：感謝我的同事張帆同學在git方面的指導

git merge 與 git rebase的區別

git merge 與 git rebase的區別

git merge 與 git rebase的區別

git merge與git rebase的區別

相關推薦