git的突出解決--git rebase之abort、continue、skip
（1）應用實例描述
假設在github或者gitoschina上建立了一個項目，默認分支為master分支，遠程master分支上c.sh文件內容：
開發者A、B分別將項目拷貝到自己本地進行開發
某一天，開發者B提交c.sh，並且提交成功，
之后，開發者A在本地代碼並沒有和遠程master分支的代碼同步的情況下，對本地的c.sh進行了修改，修改后c.sh內容如下：
修改后，開發者A准備將代碼提交到遠程master分支上。
（2）引入問題
假設開發者A提交過程如下：
$ git add c.sh
$ git commit -m "XXXX"
如果直接使用$ git push，則會報錯：
error: failed to push some refs to 'git@git.oschina.net:XXXX/gitlearning.git'
hint: Updates were rejected because the remote contains work that you do not have locally. This is usually caused by another repository pushing to the same ref. You may want to first integrate the remote changes (e.g., 'git pull ...') before pushing again. See the 'Note about fast-forwards' in 'git push --help' for details.
上述過程的節點走向如下圖所示：
實際開發過程中考慮其它開發者可能會對c.sh進行修改，因此一般在開發過程中建議使用
$ git pull --rebase
與遠程代碼同步，同步過程會檢查沖突，
此時，開發者根據 <<<<<<< HEAD，=======，>>>>>>> 便可知沖突的位置。
注意：不是出現沖突才使用git pull --rebase，它是一種解決沖突的手段，另外還有merge的方式
（3） 知識點引入
$ git pull --rebase
git pull的默認行為是git fetch + git merge
git pull --rebase則是git fetch + git rebase.
$ git fetch
從遠程獲取最新版本到本地，不會自動合並分支
$ git rebase
git rebase，顧名思義，就是重新定義（re）起點（base）的作用，即重新定義分支的版本庫狀態。本地更新分支節點過程如下圖所示。（關於rebase節點知識點可以參考http://blog.csdn.net/hudashi/article/details/7664631/）
$ git pull --rebase
git pull --rebase執行過程中會將本地當前分支里的每個提交(commit)取消掉，然后把將本地當前分支更新為最新的"origin"分支，該過程本地分支節點更新圖如下所示：
------------------------------------------------------------------------------------------
（4）回到主題
執行完git pull --rebase之后如果有合並沖突，使用以下三種方式處理這些沖突：
git rebase --abort 會放棄合並，回到rebase操作之前的狀態，之前的提交的不會丟棄；
git rebase --skip 則會將引起沖突的commits丟棄掉（慎用！！）；
git rebase --continue 合並沖突，結合"git add 文件"命令一起用與修復沖突，提示開發者，一步一步地有沒有解決沖突。（fix conflicts and then run "git rebase --continue"）
對上述沖突的處理
1、使用 $git rebase --abort
執行之后，本地內容會回到提交之間的狀態，也就是回到以前提交但沒有pull是的狀態，簡單來說就是撤銷rebase。
2、使用 $git rebase --skip
git rebase --skip 引起沖突的commits會被丟棄，對於本文應用的例子來說開發者A對c.sh文件的commit無效，開發者A自己修改的部分全部無效，因此，在使用skip時請慎重。
執行：$ vim c.sh
查看本地c.sh文件提交內容，展示如下圖所示，執行語句之后開發者A的修改無效。
3、使用 $git rebase --continue
執行完$git pull --rebase 之后，本地如果產生沖突，手動解決沖突之后，用"git add"命令去更新這些內容的索引(index)，然后只要執行:
注意：一般情況下，修改后檢查沒問題，使用rebase continue來合並沖突。
------------------------------------------------
原文：
http://gitbook.liuhui998.com/4_2.html
一、基本
git rebase用於把一個分支的修改合並到當前分支。
假設你現在基於遠程分支"origin"，創建一個叫"mywork"的分支。
$ git checkout -b mywork origin
假設遠程分支"origin"已經有了2個提交，如圖
現在我們在這個分支做一些修改，然后生成兩個提交(commit).
$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
...
但是與此同時，有些人也在"origin"分支上做了一些修改並且做了提交了. 這就意味着"origin"和"mywork"這兩個分支各自"前進"了，它們之間"分叉"了。
在這里，你可以用"pull"命令把"origin"分支上的修改拉下來並且和你的修改合並； 結果看起來就像一個新的"合並的提交"(merge commit):
但是，如果你想讓"mywork"分支歷史看起來像沒有經過任何合並一樣，你也許可以用 git rebase:
$ git checkout mywork
$ git rebase origin
這些命令會把你的"mywork"分支里的每個提交(commit)取消掉，並且把它們臨時 保存為補丁(patch)(這些補丁放到".git/rebase"目錄中),然后把"mywork"分支更新 為最新的"origin"分支，最后把保存的這些補丁應用到"mywork"分支上。
當'mywork'分支更新之后，它會指向這些新創建的提交(commit),而那些老的提交會被丟棄。 如果運行垃圾收集命令(pruning garbage collection), 這些被丟棄的提交就會刪除. （請查看 git gc)
二、解決沖突
在rebase的過程中，也許會出現沖突(conflict). 在這種情況，Git會停止rebase並會讓你去解決 沖突；在解決完沖突后，用"git-add"命令去更新這些內容的索引(index), 然后，你無需執行 git-commit,只要執行:
$ git rebase --continue
這樣git會繼續應用(apply)余下的補丁。
在任何時候，你可以用--abort參數來終止rebase的行動，並且"mywork" 分支會回到rebase開始前的狀態。
$ git rebase --abort
三、git rebase和git merge的區別
現在我們可以看一下用合並(merge)和用rebase所產生的歷史的區別：
當我們使用Git log來參看commit時，其commit的順序也有所不同。
假設C3提交於9:00AM,C5提交於10:00AM,C4提交於11:00AM，C6提交於12:00AM,
對於使用git merge來合並所看到的commit的順序（從新到舊）是：C7 ,C6,C4,C5,C3,C2,C1
對於使用git rebase來合並所看到的commit的順序（從新到舊）是：C7 ,C6‘,C5',C4,C3,C2,C1
因為C6'提交只是C6提交的克隆，C5'提交只是C5提交的克隆，
從用戶的角度看使用git rebase來合並后所看到的commit的順序（從新到舊）是：C7 ,C6,C5,C4,C3,C2,C1
另外，我們在使用git pull命令的時候，可以使用--rebase參數，即git pull --rebase,這里表示把你的本地當前分支里的每個提交(commit)取消掉，並且把它們臨時 保存為補丁(patch)(這些補丁放到".git/rebase"目錄中),然后把本地當前分支更新 為最新的"origin"分支，最后把保存的這些補丁應用到本地當前分支上。關於git pull的更多內容請參考《git pull簡介》