一、Rebase 產生意義

• 在 Git 中整合來自不同分支的修改主要有兩種方法：merge 以及 rebase。對應 merge 操作來說，想必我們都已經使用過很多次了，而 rebase 又是用在哪里呢？已經其正確的使用方式，到底是什么呢？
• 使用 Git 進行產品開發的代碼管理，勢必是會存在多人在同一個分支上協同工作的問題，這樣就很容易出現沖突。而遇到沖突的時候，一般情況都是已經有人在該分支上面提交代碼了，我們不得不先將其他的提交 pull 到本地，然后在本地合并(如果有沖突的話)，最后才能 push 成功。

$ git push origin master To github.com:xxx/xxx.git! [rejected] master -> master (fetch first) error: failed to push some refs to 'git@github.com:xxx/xxx.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

• 但是我們會發現提交記錄會變得有點亂，強迫癥的你可能需要一條干凈的直線，因為太多無用的 commit 很讓人不舒服，而且不利于每天下午的 code review 代碼檢視，同時也會污染分支提交記錄。
• 如果使用 rebase 操作的話，可以把本地未 push 的分叉提交歷史整理成直線，rebase 的目的是使得我們在查看歷史提交的變化時更容易，因為分叉的提交需要三方對比。

$ git log --graph --pretty=oneline --abbrev-commit * e0ea545 (HEAD -> master) Merge branch 'master' of github.com:xxx/xxx |\ | * f005ed4 (origin/master) add email info * | 582d922 add author info * | 8875536 add comment info |/ * d1be385 init hello repo ......

二、Rebase 合并紀錄

• rebase 會使原本分叉的提交立馬變成一條直線，這種神奇的操作，其實原理非常簡單。注意觀察，Git 把我們本地的提交“挪動”了位置，放到了 f005ed4 之后，這樣整個提交歷史就成了一條直線。rebase 操作前后，最終的提交內容是一致的，但是，本地的 commit 修改內容已經變化，它們的修改不再基于 d1be385，而是基于 f005ed4，但最后的提交 7e61ed4 內容是一致的。

$ git rebase First, rewinding head to replay your work on top of it... Applying: add comment Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py Applying: add author Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py # 再用 git log 看看發現變成直線 $ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author info * 3611cfe add comment info * f005ed4 (origin/master) add email info * d1be385 init hello repo ......

• 當然，也可以指定對最近的多少次的提交紀錄進行合并。需要注意的是，不要合并已經提交到倉庫的提交，不然會有問題。

選項列表對應含義解釋

p, pick	use commit
r, reword	use commit, but edit the commit message
e, edit	use commit, but stop for amending
s, squash	use commit, but meld into previous commit
f, fixup	like “squash”, but discard this commit’s log message
x, exec	run command (the rest of the line) using shell
d, drop	remove commit

# 合并最近的3次提交紀錄 # 之后就會自動進入vi編輯模式 $ git rebase -i HEAD~3 s 7e61ed4 add author info s 3611cfe add comment info s f005ed4 add email info# 最好編輯退出即可 # 如果你異常退出了vi窗口，不要緊張，執行下面操作即可 $ git rebase --edit-todo $ git rebase --continue

三、Rebase 分支合并

• 假設我們團隊一直在 master 分支上面開發，但是因為新功能所以切了一個 dev 分支出來。這時，同事完成了自己開發的部分 hotfix 并將其合入了 master 分支，此時我的分支已經落后于 master 分支。
• 恰巧，這時需要同步 master 分支上面的改動，進行測試，那么就需要 merge 代碼到自己的分支上。此時，我們會發現本地有一些 merge 信息。可能你會認為這樣會污染我們自己的原本干凈的提交記錄，想要保持一份干凈的提交記錄，此時，就使用 rebase。
• 使用 git rebase 命令，先回退到同事 hotfix，后合并 master 分支：
• • 首先，git 會把 dev 分支里面的每個 commit 取消掉；
• • 其次，把上面的操作臨時保存成 patch 文件，存在 .git/rebase 目錄下；
• • 然后，把dev 分支更新到最新的 master 分支；
• • 最后，把上面保存的 patch 文件應用到 dev 分支上；
• 從 commit 記錄上可以看出來，dev 分支是基于 hotfix 合并后的 master，自然而然的成為了最領先的分支，而且沒有 merge 的 commit 記錄。

# 我們自己在dev分支上面 $ git rebase master

四、Rebase 使用建議

• 使用 rebase 當中需要注意的地方：
• • 最好是該分支只有你自己在使用，否則請謹慎操作。
• • 只使用 rebase 來清理本地的提交記錄，千萬不要嘗試對已發布的提交進行操作。
• 雖然 rebase 相對于我們已知的整合操作來說有著比較顯著的優點，但是這也是在很大程度上取決于個人的喜好。一些團隊喜歡使用 rebase，而另一些可能傾向于使用 merge 合并。此外，rebase 相對于 merge 合并來說是比較復雜的，除非你和你的團隊確定會用到 rebase 操作。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Git之变基方式Rebase的使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。