From：http://blog.csdn.net/wangjia55/article/details/8776409

1.出現情況的背景：

   當你提交的程式碼後，管理員發現，您的程式碼不能提交到伺服器上，主要原因在於，你的commit 中和伺服器中的有些commit不再同一時間軸上，即：你的有些commit要插入到伺服器中的某些commit之間，這樣就會造成程式碼的衝突。所以這個時候就要使用Git rebase。

 假如，你平時使用的分支叫 new ，然後在這個分支上你剛提交過幾個commit。

 做法：

1.新建一個分支，並且程式碼和伺服器中程式碼同步

   git checkout origin/v2.0 -b temp  

2.為了保證新建的temp分支程式碼是最新的，可以多執行下面一步

  git pull

3.當你新建分支後，系統會自動checkout到temp分支上，此時

  git checkout  new

4.合併程式碼，並整理

  git rebase  temp  //會將temp分支的程式碼合併過來，並按照提交的順序排序

5.  因為順序是重新整理的，所以肯定會出現衝突

6.解決衝突，最後 git add * ，但不許要git commit

7.解決後，執行 git rebase --continue

8.重新提交程式碼： git push for-*

注意：如果要對某些程式碼的commit重新整理

1. 可以記住某個commit號

2. git rebase -i commit號

3. 會顯示一個整理提交的介面，有很多引數，e。p。等等

4.將前面的引數改為e。則wq儲存後，系統會自動讓你重新修改commit內容

5.修改完成後，再git push for-*

==========================================================================

git rebase小計(轉)

FROM：http://www.cnblogs.com/kym/archive/2010/08/12/1797937.html

PS：有的內容已修改

git rebase，顧名思義，就是重新定義（re）起點（base）的作用，即重新定義分支的版本庫狀態。要搞清楚這個東西，要先看看版本庫狀態切換的兩種情況：

1. 我們知道，在某個分支上，我們可以通過git reset，實現將當前分支切換到本分支以前的任何一個版本狀態，即所謂的“回溯”。即實現了本分支的“後悔藥”。也即版本控制系統的初衷。
2. 還有另一種情況，當我們的專案有多個分支的時候。我們除了在本地開發的時候可能會“回溯”外，也常常會將和自己並行開發的別人的分支修改新增到自 己本地來。這種情況下很常見。作為專案管理員，肯定會不斷的合併各個子專案的補丁，並將最新版本推送到公共版本庫，而作為開發人員之一，提交自己的補丁之 後，往往需要將自己的工作更新到最新的版本庫，也就是說把別的分支的工作包含進來。

舉個例子來說吧！假設我們的專案初期只有一個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

1. 這個時候，通過第一種git reset的方式，可以將master分支的當前狀態（master3）回溯到master分支的master0、master1、master2狀態。 也可已將test分支當前狀態（test2）回溯到test分支的test0、test1狀態，以及test分支的父分支master的master0、 master1狀態。
2. 那麼。如果我要讓test分支從test0到test2之間所有的改變都新增到master分支來，使得master分支包含test分支的所有修改。這個時候就要用到git rebase了。

首先，我們切換到master分支，然後執行下面的命令，即可實現我們的要求：

1

git rebase test

這個時候，git做了些什麼呢？

1. 先將test分支的程式碼checkout出來，作為工作目錄
2. 然後將master分支從test分支建立起的所有改變的補丁，依次打上。如果打補丁的過程沒問題，rebase就搞定了
3. 如果打補丁的時候出現了問題，就會提示你處理衝突。處理好了，可以執行git rebase –continue繼續直到完成
4. 如果你不想處理，你還是有兩個選擇，一個是放棄rebase過程（執行git rebase –abort），另一個是直接用test分支的取代當前分支的（git rebase –skip）。

此外，rebase還能夠讓你修訂以前提交，這個功能日後再說。

應該改為

git rebase master test

首先我們切換到test分支，再執行rebase

git checkout test
git rebase master

這個時候，git做了些什麼呢？

1. 先將test分支的程式碼checkout出來，作為工作目錄
2. 然後將master分支從test分支建立起的所有改變的補丁，依次打上。如果打補丁的過程沒問題，rebase就搞定了
3. 如果打補丁的時候出現了問題，就會提示你處理衝突。處理好了，可以執行git rebase –continue繼續直到完成
4. 如果你不想處理，你還是有兩個選擇，一個是放棄rebase過程（執行git rebase –abort），另一個是直接用test分支的取代當前分支的（git rebase –skip）。

此外，rebase還能夠讓你修訂以前提交，這個功能日後再說。

註釋：在master分支上進行rebase一般來說應該是不對的。

master分支預設是公共分支，當有多人協同時，master分支在多個地方都有副本。

如果在master分支上執行git rebase test，會把master分支的提交歷史進行修改，可以使用git log仔細觀察rebase前後，master分支上的commit hash id。

一旦修改了master的commit hash id，而如果其他人已經基於之前的commit物件做了工作，那麼當他拉取master的新的物件時，會需要在合併一次，這樣反覆下去，會把master分支搞得一團亂。

所以你的示例中master分支到提交物件master2、master3，如果已經推送到遠端，並有其他人基於master3物件進行了工作，那麼後面的結果將會變得非常的亂。

rebase的含義是把當前分支的提交物件在目標分支上重做一遍，並生成了新的提交物件。

所以如果在master分支上需要對test分支進行rebase，你需要的命令是