1 git合併程式碼方式主要有兩種方式，分別為：

(1) merge處理，這是大家比較能理解的方式。
(2) rebase處理，中文此處翻譯為衍合過程。

2 git rebase操作講解例子：

mkdir hellogit

cd hellogit # 建立hellogit目錄
git init    # 初始化git專案
vim readme  # 新建readme檔案，往裡邊新增內容
git add .   # 提交內容
git commit -m 'init project c1' # git系統預設建立一個master分支


# 接著我們建立一個dev分支，在dev分支上新增內容
git checkout -b dev    # 此處其實是兩步git branch dev加上git checkout dev
vim readme             # 在原來基礎上增加上內容
git add .
git commit -m 'add hello world c2'

# 切換回到master分支
git checkout master
vim readme           # 編輯readme檔案，在第二行增加hello world from master內容

# 此處先埋個點，因為此處會和dev分支上做的修改衝突
git add .
git commit -m 'add hello world c3'
vim hello.py         # 新新增一個hello.py檔案
git add .
git commit -m 'add hello.py c4'

# 切換回到dev分支
git checkout dev
vim helloworld.py     # 新增上helloworld.py檔案
git add .
git commit -m 'add helloworld.py c5'
 

3 至此，我們簡單分析下情況為：

master分支，節點連結串列指向為：c1<--c3<--c4
dev分支，節點連結串列指向為：c1<--c2<--c5
master分支和dev分支祖先為c1，假定在master分支上做git merge dev合併，得到的提交歷史為：
c1<--c2<--c3<--c4<--c5<--c6（c1、c4、c5做了一次三方合併發現衝突，手工處理完畢後git add/commit增加了提交節點c6）
採用git merge dev處理提交log是按照時間戳先後順序的。

假定採用的是git rebase處理過程為：

git checkout dev
git rebase master # 將dev上的c2、c5在master分支上做一次衍合處理

# git提示出現了程式碼衝突，此處為之前埋下的衝突點，處理完畢後
git add readme # 新增衝突處理後的檔案
git rebase --continue    # 加上--continue引數讓rebase繼續處理

4 此處處理後的節點為：

c1 c3 c4 c2 c5 # 此處不是按照時間順序處理的
綜合表現，git rebase可以得到一個更加簡潔的提交歷史，無需多了c6。
處理完畢後，git checkout master加上git merge dev，git會智慧採用f-f處理。

總結為：
git rebase過程相比較git merge合併整合得到的結果沒有任何區別，但是通過git rebase衍合能產生一個更為整潔的提交歷史。
如果觀察一個衍合過的分支的歷史提交記錄，看起來會更清楚：彷彿所有修改都是在一根線上先後完成的，儘管實際上它們原來是同時並行發生的。

一般我們使用衍合的目的，是想要得到一個能在遠端分支上乾淨應用的補丁，比如某個專案你不是維護者，但是想幫點忙，最好使用衍合處理。
先在自己的一個分支進行開發，當準備向主專案提交補丁的時候，根據最新的orgin/master進行一次衍合操作然後再提交，這樣維護者就不需要任何整合工作。

實際為：把解決分支補丁同最新主幹程式碼之間的衝突的責任，劃轉給由提交補丁的人來解決。
作為維護專案的人只需要根據你提供的倉庫地址做一次快進合併，或者直接採納你提交的補丁。

衍合的風險，請務必遵循如下準則：
一旦分支中的提交物件釋出到公共倉庫，就千萬不要對該分支進行衍合操作。

本文轉自：