前言

首先我们要清楚，git merge 与 git rebase 处理的问题是一样的，这两个命令都用于把一个分支的变更整合进另一个分支，只不过他们达成同样目的的方式不同。

刚开始，已经存在一条分支，这条分支的名字是base（黄色的），后来基于base分支，创建了new1分支，此时，base分支的指针和new1分支的指针都指向了base最新的提交。之后，base分支产生了新的提交，new1分支也产生了新的提交，两个分支的指针分别指向了自己分支的最新提交，换句话说就是，从分叉点开始以后，两个分支各自产生了属于自己的提交。

当前，你想把你提交的代码，从new1分支合并到base分支上，你有两种方法：merge 和 rebase。

1、使用 merge

git指令

git checkout base

git merge new1

结果：

将new1分支合并到base分支上，合并操作完成后，会产生一个新的提交（蓝色），这个新提交就是合并后的提交，它包含了两个分支中的最新代码，并且将它们合并到了一起，这个提交就是我们想要的合并后的状态，base分支的指针会指向这个新的蓝色提交，而new1分支的指针则没有移动位置，仍然指向了new1分支的最新提交（绿色）。为什么base分支的指针会指向最新的蓝色提交，而new1分支的指针却保持原位呢？原因是：在合并之前，base分支和new1分支都有属于自己独有的提交（最新的黄色提交只属于base分支，绿色提交只属于new1分支），如果我们是把new1分支合并到base分支上，就表示要把只属于new1分支上的变更合并到base分支上，对于base分支来说，会有新的变更进入，新变更进入后，base分支的内容会产生变化，所以，base分支需要一个新的提交（蓝色）来对应变化后的状态，于是，base分支的指针会指向最新产生的合并提交（蓝色），而对于new1分支来说，并没有任何内容发生变动，所以new1分支的指针仍然保持原位。

2、使用 rebase

git指令：

git checkout new1
git rebase base

结果：

• new1待变基分支、当前分支
• base 基分支、目标分支

new1分支是基于base分支的C拉出来的分支，new1的基底是C。而base在C之后有新的提交，就相当于此时要用base上新的提交来作为new1分支的新基底。实际操作为把C之后new1的提交先暂存下来，然后删掉原来这些提交，再找到base的最新提交位置，把存下来的提交再接上去（接上去是逐个和新基底处理冲突的过程），如此new1分支的基底就相当于变成了E而不是原来的C了。（注意，如果base上在C以后没有新提交，那么就还是用原来的C作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）

总结