Description
git rebase 和 git merge 一樣都是用于從一個分支獲取并且合并到當(dāng)前分支，但是他們采取不同的工作方式，以下面的一個工作場景說明其區(qū)別
場景：
如圖所示：你在一個feature分支進(jìn)行新特性的開發(fā)，與此同時，master 分支的也有新的提交。
為了將master 上新的提交合并到你的feature分支上，你有兩種選擇：merging or rebasing
merge
執(zhí)行以下命令：
git checkout feature
git merge master
或者執(zhí)行更簡單的：
git merge master feature
那么此時在feature上git 自動會產(chǎn)生一個新的commit(merge commit)
look like this：
marge 特點(diǎn)：自動創(chuàng)建一個新的commit
如果合并的時候遇到?jīng)_突，僅需要修改后重新commit
優(yōu)點(diǎn)：記錄了真實(shí)的commit情況，包括每個分支的詳情
缺點(diǎn)：因?yàn)槊看蝝erge會自動產(chǎn)生一個merge commit，所以在使用一些git 的GUI tools，特別是commit比較頻繁時，看到分支很雜亂。
rebase
本質(zhì)是變基 變基 變基
變基是什么? 找公共祖先
共同祖先是什么? 詳見參考資料2、3官方的文章
執(zhí)行以下命令：
git checkout feature
git rebase master
look like this:
rebase 特點(diǎn)：會合并之前的commit歷史
優(yōu)點(diǎn)：得到更簡潔的項(xiàng)目歷史，去掉了merge commit
缺點(diǎn)：如果合并出現(xiàn)代碼問題不容易定位，因?yàn)閞e-write了history
合并時如果出現(xiàn)沖突需要按照如下步驟解決
- 修改沖突部分
- git add
git rebase --continue- （如果第三步無效可以執(zhí)行
git rebase --skip）
不要在git add 之后習(xí)慣性的執(zhí)行 git commit命令
The Golden Rule of Rebasing rebase****的黃金法則
never use it on public branches(不要在公共分支上使用)
比如說如下場景：如圖所示
如果你rebase master 到你的feature分支：
rebase 將所有master的commit移動到你的feature 的頂端。問題是：其他人還在original master上開發(fā)，由于你使用了rebase移動了master，git 會認(rèn)為你的主分支的歷史與其他人的有分歧，會產(chǎn)生沖突。
所以在執(zhí)行g(shù)it rebase 之前 問問自己，
會有其他人看這個分支么？
if YES 不要采用這種帶有破壞性的修改commit 歷史的rebase命令
if NO ok，隨你便，可以使用rebase
Summary 總結(jié)
如果你想要一個干凈的，沒有merge commit的線性歷史樹，那么你應(yīng)該選擇git rebase
如果你想保留完整的歷史記錄，并且想要避免重寫commit history的風(fēng)險，你應(yīng)該選擇使用git merge
