git rebase 你其實可以把它理解成是「重新設定基線」，將你的當前分支重新設定開始點。
這個時候才能知道你當前分支於你需要比較的分支之間的差異。
原理很簡單：
rebase需要基於乙個分支來設定你當前的分支的基線，這基線就是當前分支的開始時間軸向後移動到最新的跟蹤分支的最後面，這樣你的當前分支就是最新的跟蹤分支。
這裡的操作是基於檔案事務處理的，所以你不用怕中間失敗會影響檔案的一致性。在中間的過程中你可以隨時取消rebase 事務。
rebase會把你當前分支的 commit 放到公共分支的最後面,所以叫變基。就好像你從公共分支又重新拉出來這個分支一樣。
舉例:如果你從 master 拉了個feature分支出來,然後你提交了幾個 commit,這個時候剛好有人把他開發的東西合併到 master 了,
這個時候 master 就比你拉分支的時候多了幾個 commit,如果這個時候你 rebase master 的話，就會把你當前的幾個 commit，放到那個人 commit 的後面。
merge 會把公共分支和你當前的commit 合併在一起，形成乙個新的 commit 提交
注意:不要在公共分支使用rebase
本地和遠端對應同一條分支,優先使用rebase,而不是merge
為什麼不要再公共分支使用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合進來的提交
更通俗的解釋一波.
比如rebase,你自己開發分支一直在做,然後某一天，你想把主線的修改合到你的分支上,做一次整合,這種情況就用rebase比較好.
把你的提交都放在主線修改的頭上
如果用merge，腦袋上頂著一筆merge的8,你如果想回退你分支上的某個提交就很麻煩,還有乙個重要的問題,rebase的話,本來我的分支是從3拉出來的,rebase完了之後,就不知道我當時是從哪兒拉出來的我的開發分支
同樣的,如果你在主分支上用rebase, rebase其他分支的修改,是不是要是別人想看主分支上有什麼歷史,他看到的就不是完整的歷史課,這個歷史已經被你篡改了
git rebase -i dev 可以將dev分支合併到當前分支
這裡的」-i「是指互動模式。就是說你可以干預rebase這個事務的過程，包括設定commit message，暫停commit等等。
git rebase –abort 放棄一次合併
1 git rebase -i dev
2 修改最後幾次commit記錄中的pick 為squash
3 儲存退出,彈出修改檔案,修改commit記錄再次儲存退出(刪除多餘的change-id 只保留乙個)
4 git add .
5 git rebase --continue
git merge 與 git rebase的區別
merge與rebase的區別 假設我們有如下圖一所示倉庫，該倉庫有master和develop兩個分支，且develop是在 3.added merge.txt file commit處從master拉出來的分支。假設現在head在 6.added hello.txt file 處，也就是在mas...
git merge 與 git rebase的區別
其實這個問題困擾我有一段時間，相信也有人和我一樣有這個困擾，網上已有很多這種解釋了，但是要麼就是無圖，要麼就是解釋的很亂，沒太看懂，經過自己對git的使用，加上向同事請教，算是理解了這個問題，所以寫下來分享一下，我盡量詳細說明 merge與rebase的區別 假設我們有如下圖一所示倉庫，該倉庫有ma...
git merge 與 git rebase的區別
前言 其實這個問題困擾我有一段時間，相信也有人和我一樣有這個困擾，網上已有很多這種解釋了，但是要麼就是無圖，要麼就是解釋的很亂，沒太看懂，經過自己對git的使用，加上向同事請教，算是理解了這個問題，所以寫下來分享一下，我盡量詳細說明 merge與rebase的區別 假設我們有如下圖一所示倉庫，該倉庫...