今天要來分享一個關於merge與rebase的差別。

此為兩者的示意圖:左為rebase，右為merge。

merge:

首先在master分支上做兩次commit，然後再額外創建一個分支feature，並也在其分支上做兩次commit，而目前這兩個分支是各自獨立的，而後我們再到master分支利用git pull將遠端的commit更新到local端，並git log ，可看出近兩次的commit，已經同步進來。

此時如果我們想將master的commit同步到feature的分支，此時我們利用git checkout feature切換到feature分支，並git log查看，也可發現最近兩次的commit，最後我們在利用 git merge master，來將master的commit同步過來。

此時，我們git log發現，master的兩次commit已經插入至我們feature兩次commit之前，並且再新增一個merge的commit。

如果一定要Push上去的話，可以透過git push (分支名) --force，強制push上去，而去遠端Github瀏覽，可發現commit已經有所改變。

rebase:

再來我們先利用rm rf- /testgit，將原本merge的folder刪除，並從遠端在重新clone一次，而後進到feature並git log，可看到最新兩次的commit。

，發現已變回原本的兩次commit。

利用git rebase (要合併進來的branch)，可以將其分支的commit插入進來，而不影響我們原分支的commit，也不會額外產生一個merge的commit，但原分支的hash value會改變。

假如我們把我們rebase的分支給Push至遠端，會發現被rejected，是因為我們通過rebase合併分支，會改變原分支commit的hash value，所以會被rejected。

Summary:

merge:
優點：記錄了真實的commit情況，包括每個分支的詳情。
缺點：因為每次merge會自動產生一個merge commit，所以在使用一些git 的GUI tools，特別是commit比較頻繁時，看到分支很雜亂。

rebase:
優點：如果我們今天在master分支不斷變化，而我其他分支要去進行同步，但如果用merge就會不斷產生merge commit，所以利用rebase可以得到更簡潔的專案歷史，去掉了merge commit。
缺點：如果今天有很多人在寫同個分支，如果因為rebase造成歷史的改變，會影響到每個人分支的使用，合併出現程式碼問題不容易定位，因為re-write了history，所以基本上不會對master做rebase。

通常我們會基於fork或其他分支進行開發，而不會直接用master進行開發，否則master會很亂，基於分支，大家相互review，降低錯誤，最後在merge到master，提高質量。