git分支的衍合

通常咱們使用衍合的目的，是想要獲得一個能在遠程分支上乾淨應用的補丁 — 好比某些項目你不是維護者，但想幫點忙的話，最好用衍合：先在本身的一個分支裏進行開發，當準備向主項目提交補丁的時候，根據最新的 origin/master 進行一次衍合操做而後再提交，這樣維護者就不須要作任何整合工做（譯註：其實是把解決分支補丁同最新主幹代碼之間衝突的責任，化轉爲由提交補丁的人來解決。），只需根據你提供的倉庫地址做一次快進合併，或者直接採納你提交的補丁。

在工做中咱們通常會有一個主分支和許多開發須要的其它分支，

提交補丁的人在編寫補丁的過程當中也提交合並了數次代碼

Master分支上的提交是維護者的提交，分支1和分支2上是提交補丁的人在編寫補丁時進行的提交，這是咱們合併一下將分支2的提交合併到分支3上作個比較

此時分支2上的B提交和分支3上的B提交的Hash值相同，是相同的一次提交

下面咱們進行衍合

從分支1向分支2衍合，獲得如今的結果，衍合的過程當中，會比較以前的每一次提交的Hash值是否相同，只要不相同就會保留在分支2全部提交的前面，若相同就會進行衝突解決，衍合後分支2上的B提交的Hash值就會發生改變，它再也不和分支3上的B提交是同一次提交，前面提到過，衍合分支的目的是將整合工做交由提交補丁的人來解決，如今就達到了這一目的

而若是以前的B提交就是從Master分支上克隆下來的

此時通過一系列操做後，提交補丁的人準備將分支2提交到Master主分支上，這時再提交就會出現這樣的狀況

通過衍合後，B提交的Hash值已經發生變化，因此分支上會出現兩個B提交