把乙個分支中的修改整合到另乙個分支的辦法有兩種：merge和rebase,
當開發程序分叉到兩個不同的分支，又各自提交了更新。
最容易的整合分支的方法是merge, 它會把兩個分支最新的快照以及兩者的共同祖先進行三方合併，合併的結果是產生乙個新的提交物件。
其實還有另外乙個選擇，可以在乙個分支裡發生的變化補丁在另乙個分支重新打一遍，這種操作叫做衍合，
rebase的作用就是把在乙個分支裡提交的改變放到另乙個分支裡重放一遍。
$ git checkout experiment$ git rebase master
它的原理是回到兩個分支最近的共同祖先，根據當前分支（也就是要進行衍合的分支experiment）後續的歷次提交物件，生成一系列檔案補丁，然後以基線分支（也就是主幹分支master）最後乙個提交物件為新的出發點，逐個應用之前準備好的補丁檔案，最後會生成乙個新的合併提交物件，從而改寫experiment的提交歷史，使它成為master分支的直接下游。
衍合最後生成的快照，其實和普通的三方合併的快照內容一模一樣。雖然最後整合得到的結果沒有任何區別，
但是衍合能產生乙個更為整潔的提交歷史。如果觀察乙個衍合過的分支的歷史記錄，看起來會更清楚：彷彿所有修改都是在一跟線上先後進行的，儘管實際上他們原本是同時並行發生的。
一般我們使用衍合的目的，是想要得到乙個能在遠端分支上乾淨應用的補丁，比如某些專案你不是維護者，但是想幫點忙的話，最好使用衍合：先在自己的乙個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的origin/master進行一次衍合操作然後再提交，這樣維護者就不需要做任何工作（實際上是把解決分支補丁同最新主幹**之間衝突的責任，轉化為由提交補丁的人來解決），維護者只需要根據你提供的倉庫位址進行一次快進合併，或者直接採納你提交的補丁。
*****=== 衍合的風險*****====
一旦分支的提交物件發布到公共倉庫，就千萬不要對該分支進行衍合操作。
進行衍合的時候，實際上拋棄了一些視訊記憶體的提交物件而創造了一些類似但不同的新的提交物件，
拋棄這些提交物件，把新的重演後的提交物件發布出去的話，你的合作者就不得不重新合併他們的工作，這樣當你再次從他們那裡獲取內容的時候，提交歷史就會變得一團糟。
/workspace/***-xx-cms:the-channel-sort$ git push origin the-channel-sort
to [email protected]:***-***-cms/***-xx-cms.git
! [rejected] the-channel-sort -> the-channel-sort (non-fast-forward)
error: failed to push some refs to '[email protected]:***-***-cms/***-xx-cms.git'
to prevent you from losing history, non-fast-forward updates were rejected
merge the remote changes (e.g. 'git pull') before pushing again. see the
'note about fast-forwards' section of 'git push --help' for details.
/workspace/***-xx-cms:the-channel-sort$ git fetch
remote: counting objects: 13, done.
remote: compressing objects: 100% (13/13), done.
remote: total 13 (delta 9), reused 0 (delta 0)
unpacking objects: 100% (13/13), done.
from bitbucket.org:***-***-***/***-xx-cms
* [new branch] production-deployment -> origin/production-deployment
* [new branch] staging -> origin/staging
/workspace/***-xx-cms:the-channel-sort$ git rebase origin/the-channel-sort
first, rewinding head to replay your work on top of it...
/workspace/***-xx-cms:the-channel-sort$ gitg
/workspace/***-xx-cms:the-channel-sort$ git push
counting objects: 35, done.
delta compression using up to 4 threads.
compressing objects: 100% (18/18), done.
writing objects: 100% (18/18), 2.29 kib, done.
total 18 (delta 14), reused 0 (delta 0)
remote:
remote: view pull request for the-channel-sort => master:
remote:
remote:
to [email protected]:***-***-cms/***-xx-cms.git
841dda2..95cdf0d the-channel-sort -> the-channel-sort
git分支的衍合
一般我們使用衍合的目的，是想要得到乙個能在遠端分支上乾淨應用的補丁 比如某些專案你不是維護者，但想幫點忙的話，最好用衍合 先在自己的乙個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的 origin master 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作 譯註 實際上是把...
git之學習要點 遠端分支與衍合
先看圖，不說話 git fetch origin 之後 注意 git fetch 命令會更新 remote 索引。看完圖之後，以下語法要搞清楚 推送本地serverfix serverfix origin git push origin serverfix 通過此語法，你可以把本地分支推送到某個命名...
git學習五（分支的衍合rebase）
它的原理是回到兩個分支最近的共同祖先，根據當前分支 也就是要進行衍合的分支experiment 後續的歷次提交物件 這裡只有乙個 c3 生成一系列檔案補丁，然後以基底分支 也就是主幹分支master 最後乙個提交物件 c4 為新的出發點，逐個應用之前準備好的補丁檔案，最後會生成乙個新的合併提交物件 ...