它的原理是回到兩個分支最近的共同祖先，根據當前分支（也就是要進行衍合的分支experiment）
後續的歷次提交物件（這裡只有乙個 c3），生成一系列檔案補丁，
然後以基底分支（也就是主幹分支master）最後乙個提交物件（c4）為新的出發點，
逐個應用之前準備好的補丁檔案，最後會生成乙個新的合併提交物件（c3'），
從而改寫experiment的提交歷史，使它成為master分支的直接下游
1） rebase應用場景
一般我們使用衍合的目的，是想要得到乙個能在遠端分支上乾淨應用的補丁 — 比如某些專案你不是維護者，
但想幫點忙的話，最好用衍合：先在自己的乙個分支裡進行開發，當準備向主專案提交補丁的時候，
根據最新的origin/master進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作
（譯註：實際上是把解決分支補丁同最新主幹**之間衝突的責任，化轉為由提交補丁的人來解決。），
只需根據你提供的倉庫位址作一次快進合併即git merge，或者直接採納你提交的補丁。
2）git rebase [主分支] [特性分支]
命令會先取出特性分支server，然後在主分支master上重演：
git rebase master server
3） 執行準則
一旦分支中的提交物件發布到公共倉庫，就千萬不要對該分支進行衍合操作。
在進行衍合的時候，實際上拋棄了一些現存的提交物件而創造了一些類似但不同的新的提交物件。
而稍後你又用git rebase拋棄這些提交物件，把新的重演後的提交物件發布出去的話，
你的合作者就不得不重新合併他們的工作，這樣當你再次從他們那裡獲取內容時，提交歷史就會變得一團糟。
如果把衍合當成一種在推送之前清理提交歷史的手段，而且僅僅衍合那些尚未公開的提交物件，就沒問題。
如果衍合那些已經公開的提交物件，並且已經有人基於這些提交物件開展了後續開發工作的話，
就會出現叫人沮喪的麻煩。
git分支的衍合
把乙個分支中的修改整合到另乙個分支的辦法有兩種 merge和rebase,當開發程序分叉到兩個不同的分支，又各自提交了更新。最容易的整合分支的方法是merge,它會把兩個分支最新的快照以及兩者的共同祖先進行三方合併，合併的結果是產生乙個新的提交物件。其實還有另外乙個選擇，可以在乙個分支裡發生的變化補...
git分支的衍合
一般我們使用衍合的目的，是想要得到乙個能在遠端分支上乾淨應用的補丁 比如某些專案你不是維護者，但想幫點忙的話，最好用衍合 先在自己的乙個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的 origin master 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作 譯註 實際上是把...
git之學習要點 遠端分支與衍合
先看圖，不說話 git fetch origin 之後 注意 git fetch 命令會更新 remote 索引。看完圖之後，以下語法要搞清楚 推送本地serverfix serverfix origin git push origin serverfix 通過此語法，你可以把本地分支推送到某個命名...