一文讀懂merge和rebase區別

什麼是rebase？

• rebase就是re + base，re表示「從新」，base表示「基礎」，即「變換基礎」的意思
• rebase從本質上講就是變換一個或多個commit的基礎，也就是上游commit，而用來作合併操做只是rebase的一種應用場景
• rebase在變換一系列commit基礎的同時，還讓咱們有機會去整理這些待rebase的commit，好比合並多個commit，修改某次commit等

這些就是rebase命令的本質,因此rebase和merge自己並不該該直接做爲兩種合併代碼的方式來比較，正確認識rebase命令是一個很重要的前提

固然，本文主要從代碼合併的場景來比較rebase和merge的區別

合併時的核心區別

rebase會改變提交歷史；merge則會保留真實的歷史

合併時的其餘區別

• merge若是不能快進合併（fast forward），就會造成一個額外的合併提交；rebase不會造成新的合併提交（但會生成要rebase的一系列commit的副原本作變基）
• rebase可用來整理待變基的一系列提交記錄，好比合並多個提交等；merge沒有這個功能

注意點

merge相對可靠，而使用rebase要注意兩點

• 當對已push到遠程的提交作rebase操做時，可能會形成遠端的提交歷史和其餘人本地不一致（因此最好不要這麼作，好比想合併多個commit成一個，要先確保這些commit沒有push到遠端）
• rebase後看不到真實的歷史記錄了（這一點看團隊規範，有的團隊喜歡rebase後一條線性的歷史記錄；但我建議用merge，雖然歷史記錄相對錯綜複雜但好在真實，能夠經過歷史記錄清楚的看到代碼演進的過程，而從複雜的歷史中剖析問題則是咱們或者其餘輔助工具應該在上層作的工做）

合併代碼log圖解

合併後能夠看到真實的提交歷史，merge後造成H這個新的合併提交（若是可快進合併則不會產生新的提交；若是可快進合併但在merge時使用了--no-ff，則仍是會產生一個新的合併提交；--no-ff好處是能夠從歷史記錄清楚的看到作了一個合併操做，而不會由於快進合併致使歷史成爲一條線）

在topic上rebase master時，git會從topic的A、B、C複製出三個新的提交（原先的A、B、C以後會被git回收掉）依次添加到master上的G提交後（可能出現三次重複的衝突，思考下爲何？能夠經過git rerere來解決，不展開說了），rebase完成後歷史記錄變成了一條線