Git rebase和merge区别详解

文章目录

- 变基的基础用法
- 变基过程中的冲突
- 解决冲突后无法push问题
- 更新变基后的代码
- 更有趣的变基用法
- 变基的风险
- 用变基解决变基
- 变基 vs 合并

此文在阅读前需要有一定的git命令基础，若基础尚未掌握，建议先阅读这篇文章Git命令播报详版

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase(变基)，本文主要讲解rebase用法。

变基的基础用法

当开发任务分叉到两个不同分支，又各自提交了更新。

整合分支最容易的方法是 merge 命令。它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（C5）并提交。

还有一种方法，你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。在 Git 中，这种操作就叫做变基（rebase）。你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

在这个例子中，你可以检出 experiment 分支，然后将它变基到 master 分支上：

git checkout experiment
git rebase master

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

现在回到 master 分支，进行一次快进合并。将 C4 中的修改变基到 C3 上

git checkout master
git merge experiment

此时，C4’ 指向的快照就和 merge示例中 C5 指向的快照一模一样了。

这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。

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

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

变基过程中的冲突

在合并中，经常会出现冲突。在解决冲突后，执行如下命令：

git add .
git rebase --continue

如果冲突无法解决可以执行 git rebase --abort取消这次合并操作。

解决冲突后无法push问题

有过git rebase经验的同学都知道，多人协作并行开发时刚解决完一堆冲突后，松了一口气，push时又提示拒绝，用-f或者--force参数强制推送，发现就推送成功了。

提交失败的原因，我个人是这么理解的，使用 rebase 之后，experiment分支上比master分支上多的修改，直接“插入”到了master分支修改的内容之后，也就是 experiment 分支的修改在 master 分支上重演了一遍，相对远程 master 分支而言，本地仓库的master分支的“基底”已经变化了，直接 push 是不行的，所以确保没有问题的情况下必须使用 --force 参数才能提交。

但很多人可能忽略了一个问题： git push --force 是不安全的。

生产过程中碰到过一次，rebase后强制push，同一分支的其他同学pull代码时出错，强行覆盖也不行。所以除非有充分的强制推送理由，其他情况下，不建议使用git push --force
这里将推荐 --force-with-lease 参数，让我们可以更安全地进行强制推送，Git 的 1.8.5 版本开始提供了这个参数，旨在解决 git push --force 命令造成的安全问题。

关于git push --force-with-lease更加详细的可以自己查查，这里推荐一篇：Git 更安全的强制推送，–force-with-lease

更新变基后的代码

更新代码使用的是 git pull origin master --rebase 而不是 git pull origin experiment。

git pull 这条命令默认使用了 --merge 的方式更新代码，如果你不指定用 --rebase，有的时候就会发现日志里有自己分支合并到了自己分支提交的提交记录。

更有趣的变基用法

在对两个分支进行变基时，所生成的“重放”并不一定要在目标分支上应用，你也可以指定另外的一个分支进行应用。如下示例，你创建了一个主题分支 server，为服务端添加了一些功能，提交了 C3 和 C4。然后从 C3 上创建了主题分支 client，为客户端添加了一些功能，提交了 C8 和 C9。最后，你回到 server 分支，又提交了 C10。

假设你希望将 client 中的修改合并到主分支并发布，但暂时并不想合并 server 中的修改，因为它们还需要经过更全面的测试。这时，你就可以使用 git rebase 命令的 --onto 选项，选中在 client 分支里但不在 server 分支里的修改（即 C8 和 C9），将它们在 master 分支上重放：

git rebase --onto master server client

以上命令的意思是：“取出 client 分支，找出它从 server 分支分歧之后的补丁，然后把这些补丁在 master 分支上重放一遍，让 client 看起来像直接基于 master 修改一样”。这理解起来有一点复杂，不过效果非常酷。

现在可以快进合并 master 分支了。（如图快进合并 master 分支，使之包含来自 client 分支的修改）：

git checkout master
git merge client

接下来你决定将 server 分支中的修改也整合进来。使用 git rebase <basebranch> <topicbranch> 命令可以直接将主题分支（即本例中的 server）变基到目标分支（即 master）上。这样做能省去你先切换到 server 分支，再对其执行变基命令的多个步骤。

git rebase master server

如图将 server 中的修改变基到 master 上所示，server 中的代码被“续”到了 master 后面。

然后就可以快进合并主分支 master 了：

git checkout master
git merge server

至此，client 和 server 分支中的修改都已经整合到主分支里了，你可以删除这两个分支，最终提交历史会变成图最终的提交历史中的样子：

git branch -d client
git branch -d server

变基的风险

变基也并非完美无缺，要用它得遵守一条准则：

如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。

变基操作的实质是丢弃一些现有的提交，然后相应地新建一些内容一样但实际上不同的提交。如果你已经将提交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作，此时，如果你用 git rebase 命令重新整理了提交并再次推送，你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合，如果接下来你还要拉取并整合他们修改过的提交，事情就会变得一团糟。

让我们来看一个在公开的仓库上执行变基操作所带来的问题。假设你从一个中央服务器克隆然后在它的基础上进行了一些开发。你的提交历史如图所示：

然后，某人又向中央服务器提交了一些修改，其中还包括一次合并。你抓取了这些在远程分支上的修改，并将其合并到你本地的开发分支，然后你的提交历史就会变成这样：

接下来，这个人又决定把合并操作回滚，改用变基；继而又用 git push --force 命令覆盖了服务器上的提交历史。之后你从服务器抓取更新，会发现多出来一些新的提交。

结果就是你们两人的处境都十分尴尬。如果你执行 git pull 命令，你将合并来自两条提交历史的内容，生成一个新的合并提交，最终仓库会如图所示：

此时如果你执行 git log 命令，你会发现你将相同的内容又合并了一次，生成了一个新的提交，会出现两个提交的作者、日期、日志居然是一样的，这会令人感到混乱。此外，如果你将这一堆又推送到服务器上，你实际上是将那些已经被变基抛弃的提交又找了回来，这会令人感到更加混乱。很明显对方并不想在提交历史中看到 C4 和 C6，因为之前就是他把这两个提交通过变基丢弃的。