什麼是 rebase?

• git rebase 你其實可以把它理解成是“重新設定基線”，將你的當前分支重新設定開始點。這個時候才能知道你當前分支於你需要比較的分支之間的差異。

• 原理很簡單：rebase 需要基於一個分支來設定你當前的分支的基線，這基線就是當前分支的開始時間軸向後移動到最新的跟蹤分支的最後面，這樣你的當前分支就是最新的跟蹤分支。這裡的操作是基於檔案事務處理的，所以你不用怕中間失敗會影響檔案的一致性。在中間的過程中你可以隨時取消 rebase 事務。

  官方解釋: https://git-scm.com/book/zh/v2/Git-分支-變基

  那麼 git rebase 和 git merge 到底有啥區別？

  rebase 會把你當前分支的 commit 放到公共分支的最後面,所以叫變基。就好像你從公共分支又重新拉出來這個分支一樣。

• eg: 如果你從 master 拉了個 feature 分支出來,然後你提交了幾個 commit ,這個時候剛好有人把他開發的東西合併到 master 了,這個時候 master 就比你拉分支的時候多了幾個 commit ,如果這個時候你 rebase develop 的話，就會把你當前的幾個 commit，放到那個人 commit 的後面。

而 merge 會把公共分支和你當前的 commit 合併在一起，形成一個新的 commit 提交

上圖解：

如下圖所示，bugfix 分支是從 master 分支分叉出來的。

使用 rebase 之後：

現在我們來簡單地講解一下合併的流程吧。

• 首先，rebase bugfix 分支到 master 分支, bugfix 分支的歷史記錄會新增在 master 分支的後面。如圖所示，歷史記錄成一條線，相當整潔。

• 這時移動提交 X 和 Y 有可能會發生衝突，所以需要修改各自的提交時發生衝突的部分。

• rebase 之後，master 的 HEAD 位置不變。因此，要合併 master 分支和 bugfix 分支，即是將 master 的HEAD移動到 bugfix 的 HEAD 這裡。

使用 merge 之後：

• merge 會把兩個分支合併在一起，形成一個新的 commit 提交

注意:

儘量不要在公共分支使用 rebase
本地和遠端對應同一條分支,優先使用 rebase ,而不是 merge

因為往後放的這些 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合進來的提交

** merge 和 rebase 實際上只是用的場景不一樣**
更通俗的解釋一波.

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

覺得有幫助的小夥伴點個