1.區別

rebase：
也稱為變基，會將當前分支的 commit 放到公共分支的最後面。就好像從公共分支又重新拉出來這個分支一樣。
舉例:如果你從 master 拉了個feature分支出來,然後你提交了幾個 commit,這個時候剛好有人把他開發的東西合併到 master 了,這個時候 master 就比你拉分支的時候多了幾個 commit,如果這個時候你rebase master 的話，就會把你當前的幾個 commit，放到那個人 commit 的後面。
merge：
會把公共分支和你當前的commit 合併在一起，形成一個新的 commit 提交。
一般來說，本地和遠端對應同一條分支,優先使用rebase,而不是merge

2.為什麼不要在公共分支使用rebase?

因為往後放的這些 commit 都是新的,這樣其他從這個公共分支拉出去的人，都需要再 rebase,相當於你 rebase 東西進來，就都是新的 commit 了

• 1-2-3 是現在的分支狀態
• 這個時候從原來的master ,checkout出來一個prod分支
• 然後master提交了4.5，prod提交了6.7
• 這個時候master分支狀態就是1-2-3-4-5，prod狀態變成1-2-3-6-7
• 如果在prod上用rebase master ,prod分支狀態就成了1-2-3-4-5-6-7
• 如果是merge
  1-2-3-6-7-8
  …….. |4-5|
• 會出來一個8，這個8的提交就是把4-5合進來的提交

3.merge和rebase實際上只是用的場景不一樣

比如rebase,你自己開發分支一直在做,然後某一天，你想把主線的修改合到你的分支上,做一次整合,這種情況就用rebase比較好.把你的提交都放在主線修改的頭上
如果用merge，腦袋上頂著一筆merge的8,你如果想回退你分支上的某個提交就很麻煩,還有一個重要的問題,rebase的話,本來我的分支是從3拉出來的,rebase完了之後,就不知道我當時是從哪兒拉出來的我的開發分支
同樣的,如果你在主分支上用rebase, rebase其他分支的修改,是不是要是別人想看主分支上有什麼歷史,他看到的就不是完整的歷史課,這個歷史已經被你篡改了。

4.如果在master分支下面搞一個新的分支，開發的同時，master有了新增程式碼，然而需要在新的master上面繼續開發，怎麼辦呢？

1、先把自己寫的程式碼，儲存到本地庫，然後推送到來遠端庫（至關重要），然後拉下來遠端庫，這很重要
2在git命令中輸入：git rebase origin/master,這樣就會把現在正在開發的分支中已經寫好的程式碼與最新的master分支的程式碼融合在一起
3.輸入 git status 顯示衝突的檔案，然後找到那個檔案解決衝突，git add 檔名,這樣才算解決一個衝突，輸入 git rebase --continue ，繼續git status ....... 知道所有的衝突全部解決
（git status如果不顯示衝突檔案，但又處於rebase狀態，輸入git rebase --skip)
如果不想解決衝突了，輸入 git rebase --abort ，回到最初的狀態，前面解決的所有衝突都會恢復到以前的狀態
4.解決完衝突後，推送到遠端庫。

參考連結：
https://www.jianshu.com/p/4079284dd970
https://git-scm.com/book/zh/v2/Git