git rebase，顧名思義，就是重新定義（re）起點（base）的作用，即重新定義分支的版本庫狀態。要搞清楚這個東西，要先看看版本庫狀態切換的兩種情況：
- 我們知道，在某個分支上，我們可以通過git reset，實現將當前分支切換到本分支以前的任何一個版本狀態，即所謂的“回溯”。即實現了本分支的“后悔葯”。也即版本控制系統的初衷。
- 還有另一種情況，當我們的項目有多個分支的時候。我們除了在本地開發的時候可能會“回溯”外，也常常會將和自己並行開發的別人的分支修改添加到自 己本地來。這種情況下很常見。作為項目管理員，肯定會不斷的合並各個子項目的補丁，並將最新版本推送到公共版本庫，而作為開發人員之一，提交自己的補丁之 后，往往需要將自己的工作更新到最新的版本庫，也就是說把別的分支的工作包含進來。
舉個例子來說吧！假設我們的項目初期只有一個master分支，然后分支上作過兩次提交。這個時候系統只有一個master分支，他的分支歷史如下：
master0（初始化后的版本）
||
v
master1（第一次提交后的版本）
||
v
master2（第二次提交后的版本）
這個時候，我們可以通過git reset將master分支（工作目錄、工作緩存或者是版本庫）切換到master1或者master0版本，這就是前面所說的第一種情況。
假設我們這里把master分支通過git reset回溯到了master1狀態。那么這個時候系統仍然只有一個master分支，分支的歷史如下：
master0（初始化后的版本）
||
v
master1（第一次提交后的版本）
然后，我們在這里以master1為起點，創建了另一個分支test。那么對於test分支來說，他的第一個版本test0就和master1是同一個版本，此時項目的分支歷史如下：
master0（初始化后的版本）
||
v
master1（第一次提交后的版本）===test0（test分支，初始化自master分支master1狀態）
這個時候，我們分別對master分支、test分支作兩次提交，此時版本庫應該成了這個樣子：
master0（初始化后的版本）
||
v
master1===test0==>test1===>test2
||
v
master2===>master3
- 這個時候，通過第一種git reset的方式，可以將master分支的當前狀態（master3）回溯到master分支的master0、master1、master2狀態。 也可已將test分支當前狀態（test2）回溯到test分支的test0、test1狀態，以及test分支的父分支master的master0、 master1狀態。
- 那么。如果我要讓test分支從test0到test2之間所有的改變都添加到master分支來，使得master分支包含test分支的所有修改。這個時候就要用到git rebase了。
首先，我們切換到master分支，然后運行下面的命令，即可實現我們的要求：
1 |
git rebase test |
這個時候，git做了些什么呢？
- 先將test分支的代碼checkout出來，作為工作目錄
- 然后將master分支從test分支創建起的所有改變的補丁，依次打上。如果打補丁的過程沒問題，rebase就搞定了
- 如果打補丁的時候出現了問題，就會提示你處理沖突。處理好了，可以運行git rebase –continue繼續直到完成
- 如果你不想處理，你還是有兩個選擇，一個是放棄rebase過程（運行git rebase –abort），另一個是直接用test分支的取代當前分支的（git rebase –skip）。
此外，rebase還能夠讓你修訂以前提交，
git rebase -i HEAD~3
表示要修改當前版本的倒數第三次狀態。
這個命令出來之后，會出來三行東東：
pick:*******
pick:*******
pick:*******
如果你要修改哪個，就把那行的pick改成edit，然后退出。
這時通過git log你可以發現，git的最后一次提交已經變成你選的那個了，這時再使用：
git commit -amend
來對commit進行修改。
修改完了之后，要回來對不對？
使用git rebase --continue
git reset --soft 只會改變狀態，不會改變工作區內容
git reset --hard 既會改變狀態也會改變工作區內容