git rebase命令是一個神奇的git命令，初學者應該少用這個命令，但是如果你真正的瞭解rebase命令，那它會幫助你省去很多的麻煩。今天我們就詳細的分析rebase和merge兩個命令。
概述
git rebase和merge兩個命令的功能是非常相識的，他們都會把一個分支上的變更合入到另一個分支中去，只是他們採用了完全不一樣的設計思路。
想象一個非常常見的場景：你新建了一個feature分支，並且在這個分支上開發一個新的特性，這個時候有一個同事需要把他的commit合併到master分支上去。
常見的場景
這個時候如果合入的Master的commit需要依賴你的feature分支中的特性的時候，那麼你有兩個命令可以選：merge和rebase。
Merge命令
最簡單的方法就是使用如下的命令把master分支的代碼合併到feature分支中去：
git checkout feature
git merge master
這將在feature分支中創建一個新的“merge commit”，它將兩個分支的歷史聯繫起來，最終得到一個類似於此的分支結構：
git merge命令圖解
Merge操作是一個非常好的選擇，因為它是非破壞性的操作。已經存在的分支不會有任何的變化，如果需要進行回滾或者查看變更記錄會非常的方便。
但是這也意味著每一次合併都需要有一個無效的“merge commit”，如果merge操作非常頻繁的化，這會汙染分支變更歷史，會讓變更歷史非常的難以理解。
Rebase命令
作為merge命令的替代方案，你可以把feature分支的代碼直接rebase到master分支上去。命令格式如下：
git checkout feature
git rebase master
這個命令會把feature分支直接嫁接到master末尾，從而把所有的feature上的變更都合併到master上去。和merge命令不同的是，rebase命令不會創建一ge類似與“merge commit”的提交，但是會把feature分支上的每一個commit在master分支上創建一個新的commit。
git rebase命令圖解
使用rebase命令的主要好處是，你得到一個更清潔項目歷史。首先，它消除了Git合併所需的不必要的合併提交。其次，你可以看到上面的圖，rebase能夠得到一個完美的線性項目歷史。這使得它更容易與git log之類的命令來查看git commit的歷史。
但是，這種操作需要有兩種權衡：安全性和可追溯性。如果你不遵循Rebase命令的黃金規則，重新書寫項目commit歷史可能會為你的項目工作流帶來災難性的後果。
交互式的Rebase
交互式的Rebase讓我們有機會把commit rebase到新的分支上去的時候，記錄下rebase進來的commit信息，這會比直接rebase好上許多，因為這樣知道rebase命令是在什麼時候執行的，並且哪些commit被rebase到新的分支裡來了。通過如下命令：
git checkout feature
git rebase -i master
這個時候會打開一個文本編輯器，並且列出了會被rebase的commit的信息。
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
Rebase命令的黃金法則
如果你對rebase有了非常清除的認識，那麼最應該知道的事情是：rebase命令在什麼時候不能使用。使用rebase命令的黃金法則就是：不要在公共分支中使用。
比如：你把master分支rebase到你自己的feature分支上去了，但是其他開發同學並不知道這個事情，他們還會使用之前master分支，這顯然會帶來很多問題的。
git rebase可能遇到的場景
閱讀更多 java小碼農 的文章
