使用 Git 很久了，一直以为对于常用的这些命令已经很了解了，可是突然发现对于很多东西的理解都太过浅显，于是不得不回过头来补课。

大概就是传说中的「too young too simple」。

我们知道 merge 和 rebase 都是 git 中用来合并代码的常用操作，用于从一个分支获取并且合并到当前分支，但是他们有什么区别或者优缺点分别是什么，在使用的时候应该怎么选择呢？如果你跟我一样不是很清楚可以继续读下去了。

merge 和 rebase 的区别

场景：

如图所示，假设你的项目有一个公用的主分支 master，而你正在 feature 分支上开发一个新功能，同时 master 分支也会有新的更新。

在某些场景下，你必须要将 master 分支上的代码同步到自己的 feature 分支上或者是将自己的 feature 分支上的修改合并到 master 分支，这个时候你就会有两种选择：merging 或 rebasing。

merge

以将 feature 分支合并到 master 分支为例，先将分支切到 master 上，然后执行 merge 命令，代码如下：

git checkout master
git merge feature

或者你也可以把他们压缩成一行

git merge feature master

此时就会自动在 master 分支上产生一个新的 commit（merge commit），如下图所示：

merge 的特点：

• 自动创建一个 commit
• 如果 merge 过程中出现冲突仅需要修改一个 commit

merge 的优点是它记录了真实的 commit 情况，包括每个分支的详情，哪个分支上做了些什么事情都可以从提交历史中看出来；但是缺点是每一个 merge 操作都会自动生成一个 merge commit，对于需要频繁合并的分支来说，commits 历史就会显得比较杂乱。

rebase

如果使用 rebasing 的方式，执行下列命令：

git checkout master
git rebase feature

最终的 commit 结果如图所示：

从图中可以看出，rebase 执行的结果是一条直线，并且没有自动生成的 merge commit，这也正是 rebase 的特点，它会根据 commit 的时间点进行合并，最终形成一条直线。

这样做的优点是使得最终的 commit 历史变得更加简洁和美观，但是也造成了出了问题不好追踪 commit 历史的问题，因为 commits 已经被 re-write 了。

在出现冲突的时候，使用如下步骤解决冲突：

• 修改冲突部分
• git add
• git rebase --continue

如果不想进行此次 rebase 操作执行 git rebase --abort

如何选择

知道了 merge 和 rebase 的区别，那么在实际项目上我们应该如何选择呢？

rebase 的黄金法则

git rebase 的黄金法则是，绝不要在公共的分支上使用它。

假设你想要将 master 分支合并到你的 feature 分支上，你执行了 rebase 操作，这时 master 分支上的提交会追加到 feature 分支的后面，但是这时其他人还在 master 分支上工作，由于你的 rebase 操作移动了 master 分支，git 会认为你的主分支的历史和其他人的有分歧，就会产生冲突。

而同步这两个分支的唯一办法就是使用 merge 操作，生成一个额外的 commit 包含所有的提交，这或许会让人很头大。

所以我们在选择是否使用 rebase 的时候可以问问自己「是否有人正在这个分支上工作？」

如果答案是肯定的，那最好不要使用 rebase，如果不是，那么就可以随意了。

总结

不能说哪种方法好或不好，只有基于自己目前的项目状况哪个更合适一些，如果你希望保留完整的 commits history，对于产生的 merge commit 并不 care 的话就可以使用 merge，如果更在意 history 的整洁性并且保证使用 rebase 不会影响其他人的话就用 rebase。

参考资料

https://github.com/geeeeeeeeek/git-recipes/wiki/5.1-%E4%BB%A3%E7%A0%81%E5%90%88%E5%B9%B6%EF%BC%9AMerge%E3%80%81Rebase-%E7%9A%84%E9%80%89%E6%8B%A9
https://www.jianshu.com/p/c17472d704a0
https://www.zhihu.com/question/36509119