Description

git rebase 和 git merge 一樣都是用於從一個分支獲取並且合併到當前分支，但是他們採取不同的工作方式，以下面的一個工作場景說明其區別

場景：

如圖所示：你在一個feature分支進行新特性的開發，與此同時，master 分支的也有新的提交。

為了將master 上新的提交合併到你的feature分支上，你有兩種選擇：merging or rebasing

merge

執行以下命令：

git checkout feature
git merge master

或者執行更簡單的：

git merge master feature
 

那麼此時在feature上git 自動會產生一個新的commit(merge commit)
look like this：

marge 特點：自動建立一個新的commit
如果合併的時候遇到衝突，僅需要修改後重新commit
優點：記錄了真實的commit情況，包括每個分支的詳情
缺點：因為每次merge會自動產生一個merge commit，所以在使用一些git 的GUI tools，特別是commit比較頻繁時，看到分支很雜亂。

rebase

本質是變基 變基 變基
變基是什麼? 找公共祖先

執行以下命令：

git checkout feature
git rebase master
 

look like this:

rebase 特點：會合並之前的commit歷史
優點：得到更簡潔的專案歷史，去掉了merge commit
缺點：如果合併出現程式碼問題不容易定位，因為re-write了history

合併時如果出現衝突需要按照如下步驟解決

修改衝突部分

git add
git rebase --cotinue

（如果第三步無效可以執行 git rebase --skip）
不要在git add 之後習慣性的執行 git commit命令

The Golden Rule of Rebasing rebase的黃金法則

never use it on public branches(不要在公共分支上使用)

比如說如下場景：如圖所示

如果你rebase master 到你的feature分支：

rebase 將所有master的commit移動到你的feature 的頂端。問題是：其他人還在original master上開發，由於你使用了rebase移動了master，git 會認為你的主分支的歷史與其他人的有分歧，會產生衝突。

所以在執行git rebase 之前 問問自己，

會有其他人看這個分支麼？

if YES 不要採用這種帶有破壞性的修改commit 歷史的rebase命令
if NO ok，隨你便，可以使用rebase
Summary 總結

如果你想要一個乾淨的，沒有merge commit的線性歷史樹，那麼你應該選擇git rebase
如果你想保留完整的歷史記錄，並且想要避免重寫commit history的風險，你應該選擇使用git merge

(轉載)