git rebase 與 git merge 的區別

前言

初學git，在合併分支上一定會經常使用到 git merge 語法。今日接觸到 git rebase，發現兩者都有用於分支合併的功能，那接下來讓咱們探究一下兩者的不一樣之處。

開門見山：兩者的區別

主要區別在於git log上：是否保留分支的commit提交節點 。

其次細講：詳情分析

前提：

1. 在一個git項目中我先建立並保存了兩個文檔：1.txt 和 2.txt 記做「1」 和 「2」；
2. 建立分支branch1；
3. 繼續在主分支Master上建立並保存兩個文檔：3.txt 和 4.txt 記做「3」 和 「4」；
4. 轉到branch1分支上建立 5.txt 和 6.txt 記做「5」 和 「6」；

此時，咱們的主分支Master上有一、二、三、4 四個文檔，branch1分支上則是一、二、五、6 四個文檔，接下來執行咱們的合併操做。

• git merge：

  咱們直接回到主分支Master上執行 git merge 命令，顯示以下：

此時咱們的 git log 上保留了分支branch1的 5 和 6 的commit提交，且又在主分支Master上自動建立了一個新的commit提交節點 「7」。

簡單而言就是Master的一、二、三、4和合並的branch1的五、6的提交歷史節點都被記錄下來了，且自動在Master上自動生成第7個節點：

• git rebase：

  咱們在分支branch1上執行 git rebase 命令：

會發現branch1合併了 Master 的 三、4 文檔，因此如今branch1 就有了一、二、三、四、五、6全部文檔，回到Master再合併一下：

這時咱們的 git log 上就獲得一個簡潔的項目歷史，且未生成新的 merge commit（保留了分支上的提交信息成功與Master合併，但刪去了提交歷史記錄）：

• 自我猜測：

學完rebase，我即刻猜測，如果在分支baranch1上直接merge合併主分支，獲得全部文檔後再回到主分支上執行merge會不會也能獲得一條線，事實證實，這麼想說明仍是沒有徹底理解rebase的真正含義，先看結果吧...

rebase 究竟是什麼？

rebase就是——變基， 變基， 變基 。

即：改變一條分支的 基點 ，使原分支從指定的節點（commit）延續。。

通俗點講，變基操做其實就是保留了該 commit 做出的修改，但刪丟棄了分支上一些現有的提交記錄，刪去了這些節點。

最後結論：兩者比較

比較	merge	rebase
優勢	保留有價值的歷史文檔	刪減就繁
缺點	分支雜亂冗餘	沒法體現時間線

因此，使用merge仍是rebase仍是得分狀況考慮，具體項目具體分析：

• 若是項目龐大，須要一個簡潔的線性歷史樹便於leader管理，推薦使用 git rebase 。
• 若是是小型項目，須要審查歷史紀錄來便於編寫過程報告，則推薦使用 git merge 。