原始分支自然是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分支上。