目录

• 1.1 merge合并命令
• 1.2 merge合并原理
• 2.1 rebase变基命令
• 2.2 rebase变基原理
• 3 用变基还是合并
• 4 参考

  1.1 merge合并命令

  merge是合并的意思，主要的功能是把两个分支合并成一个分支，比如下图：
  
  为了合并master和iss53两个分支，分以下几步：

1. 通过git checkout master 切换到master分支（当然切换到iss53分支也可以，不过合并后的分支名就是iss53了）
2. 执行git merge iss53进行合并（如果切换到iss53分支，则执行git merge master）
3. 执行合并动作可能存在冲突，因此要进行手动消除冲突
4. 消除冲突后，执行git add file提交到暂存区

合并后的结果，如下图：

1.2 merge合并原理

Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。需要指出的是，Git 会自行决定选取哪一个提交作为最优的共同祖先，并以此作为合并的基础

2.1 rebase合并命令

使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。
以下图为例：

运行命令：

//切换到要变基的分支experiment
$ git checkout experiment
//执行变基，即在master分支上重放
$ git rebase master

变基后的结果如下图：

2.2 rebase变基原理

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

用合并还是变基？

在回答这个问题之前，让我们退后一步，想讨论一下提交历史到底意味着什么。

有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

现在，让我们回到之前的问题上来，到底合并还是变基好？希望你能明白，这并没有一个简单的答案。 Git 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法，相信你能够根据实际情况作出明智的选择。

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。

参考

https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA