git合並代碼方式主要有兩種方式，分別為：
1、merge處理，這是大家比較能理解的方式。
2、rebase處理，中文此處翻譯為衍合過程。
git rebase操作講解例子：
cd /usr/local/test 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'
至此，我們簡單分析下情況為：
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繼續處理
此處處理后的節點為：
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進行一次衍合操作然后再提交，這樣維護者就不需要任何整合工作。
實際為：把解決分支補丁同最新主干代碼之間的沖突的責任，划轉給由提交補丁的人來解決。
作為維護項目的人只需要根據你提供的倉庫地址做一次快進合並，或者直接采納你提交的補丁。
衍合的風險，請務必遵循如下准則：
一旦分支中的提交對象發布到公共倉庫，就千萬不要對該分支進行衍合操作。
因為rebase操作會將歷史commit 合並成一次commit。這樣回滾的時候，就會有問題。