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提交