原始分支自然是master,从master中创建了一个新的分支,名为new。然后new分支上增加了一些文件,修改了一些文件并提交了。同时也在master分支里修改了一些文件,增加了一些文件。这样一来,当前的分支情况大概就是这样:

下面,我们假设以master为主线,new分支为被合并对象,开始我们的分支合并过程:

  • 首先,切换到主线分支上来git co master -m

  • 然后,在主线上执行合并git merge new

  • 接着,切换到new分支git co new -m

  • 最后,将其更新以包括主分支上的修改git rebase master

切换分支的时候,增加了-m参数。这是因为我的各个分支都是并行开发的,每个分支的work tree都有未提交的更改。所以使用这个选项,使得git切换分支时,发现wor tree和要切换分支上次缓存的内容不一样时,自动合并(其实结果就相当于是保留work tree的所有更改)

另外,我的运气比较好。

  • 一来两个分支新增加的文件相互不冲突,所以合并分支的时候很简单。

  • 二来两个分支同时修改(即冲突)的文件修改的内容很简单,所以git能够自动合并。所以整个过程很顺利。

如果两个分支有冲突的文件,而且git自己无法自动解决冲突,那么就需要在第二步之后,手动解决这些冲突,并运行git ci -m “解决XXX冲突"来提交,然后才能完成合并。合并后的效果图类似:

看日志其实很容易明白,所谓的分支合并,就是将被合并的分支的各次提交,依次应用到主线上来。以本文为例,master分支保持不便,将new分支的各次提交生成patch,然后按照提交先后顺序,依次将补丁patch到master分支上。