git合並代碼方式主要有兩種方式，分別為：
1、merge處理，這是大家比較能理解的方式。
2、rebase處理，中文此處翻譯為衍合過程。

git rebase操作講解例子：

 1 cd /usr/local/test
 2 mkdir hellogit
 3 cd hellogit # 創建hellogit目錄
 4 git init # 初始化git項目
 5 vim readme # 新建readme文件，往裏邊添加內容
 6 git add . # 提交內容
 7 git commit -m ‘init project c1‘ # git系統默認創建一個master分支
 8 
 9 # 接著我們創建一個dev分支，在dev分支上添加內容
 
10 git checkout -b dev # 此處其實是兩步git branch dev加上git checkout dev
11 vim readme # 在原來基礎上增加上內容
12 git add .
13 git commit -m ‘add hello world c2‘
14 
15 # 切換回到master分支
16 git checkout master
17 vim readme # 編輯readme文件，在第二行增加hello world from master內容
18 # 此處先埋個點，因為此處會和dev分支上做的修改沖突
19 git add .
20 git commit -m ‘
 
add hello world c3‘
21 vim hello.py # 新添加一個hello.py文件
22 git add .
23 git commit -m ‘add hello.py c4‘
24 
25 # 切換回到dev分支
26 git checkout dev
27 vim helloworld.py # 添加上helloworld.py文件
28 git add .
29 git commit -m ‘add helloworld.py c5‘

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

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處理過程為：

1 git checkout dev
2 git rebase master # 將dev上的c2、c5在master分支上做一次衍合處理
3 # git提示出現了代碼沖突，此處為之前埋下的沖突點，處理完畢後
4 git add readme # 添加沖突處理後的文件
5 git rebase --continue # 加上--continue參數讓rebase繼續處理

此處處理後的節點為：

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進行一次衍合操作然後再提交，這樣維護者就不需要任何整合工作。

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

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

參考：https://www.cnblogs.com/pinefantasy/articles/6287147.html

Git-git rebase詳解