git merge squash 和 rebase 区别

在合并分支的时候，默认是有三种选项的，分别是

普通的 merge
squash merge
rebase merge

普通 Merge

说到合并分支，可能我们最熟悉的操作是这样的：

先切换到目标分支：git checkout master
执行命令：git merge devel
删除旧分支（可以在上面一同做）：git branch -D devel
提交到远程分支：git push origin master

假设合并之前的这样的：

我们这么上述操作之后，分支的 commit 历史将会是这样的：

看上去是一条直直的 commit line，我们在 devel 分支中的 commit 也是一个不差得保留在了 master 中。但是很多时候，我们并不需要那么多的 commit，假设你给一个开源项目提交一个 Bug Fixes，然后一个简单的修改因为你的粗心大意 pull request 了十几个 commit 过去，如果作者给你 merge 了，这就在这个项目的历史长河中增加了十几个 commit 啊，以后的人看 commit history 估计都崩溃了吧；同时，当你 merge 之后发现有问题，想回滚都麻烦。

squash merge

在使用 git 的过程中，可能你遇到过想要合并多个 commit 为一个，然后很多人会告诉你用 git commit --amend，然后你发现里面有你的多个 commit 历史，你可以通过 pick 选择，squash 合并等等。同样得，merge 的时候也可以这么干，你只需要这么简单的两步：

切换到目标分支：git checkout master
以 squash 的形式 merge：git merge --squash devel

你会发现，在 master 分支上居然有未提交的修改，然后你就需要在 master 上主动提交了修改，注意，这里是你 commit 的，也就是改变了 commit 的 author。结果是这样的：

比前面普通的 merge 来说，我们只有一个 commit 了，不管在分支中 commit 了多少，这里都只有一个。

rebase merge

我们既想合并 commits，又想保留作者的信息，那么有没有什么好办法呢？肯定是有的啦，这个时候我们可以尝试一下 rebase，操作步骤是这样的：

先切换到 devel 分支：git checkout devel
变基：git rebase -i master
切换回目标分支：git checkout master
合并: git merge devel

这里完成了第二步之后我想你应该大概知道发生了什么事了，我们在 devel 里面对照 master 进行了变基，所谓的变基其实就是找到两个分支共同的祖先，然后在当前分支上合并从共同祖先到现在的所有 commit，所以我们在第二步的时候会选择怎么处理这些 commit，然后我们就得到了一个从公共commit 到现在的单个 commit，这个时候别人讲我们这个 commit 合并到 master 也只会在 master 上留下一个 commit 记录，就像这样：

虽然这个 commit history 线看上去很不错，而且也比较符合实际情况，但是我们需要注意到的有点就是分支上的开发者需要自己执行变基操作，从而导致他的原始 commit history 变化了（可以理解成被合并了）。

总结

rebase 可以保持 master 分支整洁，易于识别 author，容易回滚
squash 可以保持 master 分支整洁，但是 master 中 author 都是 maintainer，而不是原 owner，容易回滚
普通merge 不能保持 master 分支整洁，但是保持了所有的 commit history, 回滚时麻烦

操作复杂程度 rebase > squash > 普通merge
回滚复杂度 rebase = squash > 普通merge

在线模拟git 合并，请访问 learn-git-branching

参考资料

learn-git-branching
merge squash 和 merge rebase 区别