1. 变基

1.1. 合并

假设现在的分支提交情况如下：

如果想把master分支的改动，『合并』到experiment分支，通常我们用 git merge 命令，如下：

# 1. 先切换到experiment分支
git checkout experiment

# 2. 合并master分支到当前分支
git merge master

合并后的结果如下：

可以看到，多出了一个『C5』的提交，将master上的提交快照合并到experiment上。合并后可以看到各个分支的改动历史。

2. 变基

同样，还是想把master分支的改动，『合并』到experiment分支，我们还可以使用『变基』，操作如下：

# 1. 先切换到experiment分支
git checkout experiment

# 2. 变基master
git rebase master

# 3. 会有如下输出
# First, rewinding head to replay your work on top of it...
# Applying: added staged command

变基后的结果如下：

变基的原理是首先找到这两个分支（即当前分支 experiment 、变基操作的目标基底分支 master ）的最近共同祖先 C2 ，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3 , 最后以此将之前另存为临时文件的修改依序应用。

git rebase 从最终结果上来看，跟 git merge 一样，都是将另外一个分支的内容『合并』到本分支，不同的是，在查看经过变基的分支的历史记录时会发现：
尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。

一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁—例如向某个其他人维护的项目贡献代码时。
在这种情况下，你首先在自己的分支里进行开发，当开发完成时你需要先将你的代码变基到 origin/master 上，然后再向主项目提交修改。

这样的话，该项目的维护者就不再需要进行整合工作，只需要快进合并便可。

请注意，无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。
变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。

3. rebase理解

在当前分支（假设为experiment） git rebase master，相当于说再一次以最新的master分支为基础，新建experiment分支，然后再把当前experiment分支的commit续上去。