把乙個分支中的修改整合到另乙個分支的辦法有兩種：merge 和 rebase（譯註：rebase 的翻譯暫定為「衍合」，大家知道就可以了。）。在本章我們會學習什麼是衍合，如何使用衍合，為什麼衍合操作如此富有魅力，以及我們應該在什麼情況下使用衍合。
請回顧之前有關合併的一節（見圖 3-27），你會看到開發程序分叉到兩個不同分支，又各自提交了更新。
圖 3-27. 最初分叉的提交歷史。
之前介紹過，最容易的整合分支的方法是 merge 命令，它會把兩個分支最新的快照（c3 和 c4）以及二者最新的共同祖先（c2）進行三方合併，合併的結果是產生乙個新的提交物件（c5）。如圖 3-28 所示：
圖 3-28. 通過合併乙個分支來整合分叉了的歷史。
其實，還有另外乙個選擇：你可以把在 c3 裡產生的變化補丁在 c4 的基礎上重新打一遍。在 git 裡，這種操作叫做衍合（rebase）。有了 rebase 命令，就可以把在乙個分支裡提交的改變移到另乙個分支裡重放一遍。
在上面這個例子中，執行：
$ git checkout experiment
$ git rebase master
first, rewinding head to replay your work on top of it...
圖 3-30. master 分支的快進。
現在的 c3』 對應的快照，其實和普通的三方合併，即上個例子中的 c5 對應的快照內容一模一樣了。雖然最後整合得到的結果沒有任何區別，但衍合能產生乙個更為整潔的提交歷史。如果視察乙個衍合過的分支的歷史記錄，看起來會更清楚：彷彿所有修改都是在一根線上先後進行的，儘管實際上它們原本是同時並行發生的。
一般我們使用衍合的目的，是想要得到乙個能在遠端分支上乾淨應用的補丁 — 比如某些專案你不是維護者，但想幫點忙的話，最好用衍合：先在自己的乙個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的 origin/master 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作（譯註：實際上是把解決分支補丁同最新主幹**之間衝突的責任，化轉為由提交補丁的人來解決。），只需根據你提供的倉庫位址作一次快進合併，或者直接採納你提交的補丁。
請注意，合併結果中最後一次提交所指向的快照，無論是通過衍合，還是三方合併，都會得到相同的快照內容，只不過提交歷史不同罷了。衍合是按照每行的修改次序重演一遍修改，而合併是把最終結果合在一起。
git學習五（分支的衍合rebase）
它的原理是回到兩個分支最近的共同祖先，根據當前分支 也就是要進行衍合的分支experiment 後續的歷次提交物件 這裡只有乙個 c3 生成一系列檔案補丁，然後以基底分支 也就是主幹分支master 最後乙個提交物件 c4 為新的出發點，逐個應用之前準備好的補丁檔案，最後會生成乙個新的合併提交物件 ...
git分支的衍合
把乙個分支中的修改整合到另乙個分支的辦法有兩種 merge和rebase,當開發程序分叉到兩個不同的分支，又各自提交了更新。最容易的整合分支的方法是merge,它會把兩個分支最新的快照以及兩者的共同祖先進行三方合併，合併的結果是產生乙個新的提交物件。其實還有另外乙個選擇，可以在乙個分支裡發生的變化補...
git分支的衍合
一般我們使用衍合的目的，是想要得到乙個能在遠端分支上乾淨應用的補丁 比如某些專案你不是維護者，但想幫點忙的話，最好用衍合 先在自己的乙個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的 origin master 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作 譯註 實際上是把...