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