Git：图解 merge 和 rebase 的区别

 在 Git 的交汇处，每一次选择都是代码旅程的新起点。

在 Git 中，Merge 和 Rebase 是两种常用的分支整合方式，但是一些初学的小伙伴可能不知道它们之间有什么区别，以及二者该怎么选择。

本文将深入探讨 Merge 和 Rebase 的区别，帮助你更好地理解和运用它们，以提高代码管理的效率和质量。

场景 | 举个栗子

为了彻底地搞懂它们之间的区别，不妨先举个例子，假设现在有一个 main 分支和一个 feature 分支，如图（图中数字为提交的先后次序，即最早的提交是1，然后是2，其次是3）：

而你正在开发 feature 分支，目前最新的提交是4，但是你的同事突然向 main 分支推送了一个提交5 ， 而且恰巧提交5中的某些代码你正好需要用到，此时你的想法肯定是将 main 分支中的代码合并到你的 feature 分支中来。

Merge | 分支交汇的交叉路口

Merge的原理很简单，就是将要合并分支的最新提交组合成一个新的提交，并且插入到目标分支中。

现在你想要把 main 分支 merge 到你的 feature 分支上去，那么 git 会把两个分支的最新提交4和5合并成一个提交，并且合入目标分支 feature，也就是：

git checkout feature
git merge main  

最终会得到：

现在，你同事的代码已经合并到你的 feature 分支中来了，你也可以愉快地开始编写代码了！  

不过有一个比较难受的地方就是，假设在你开发 feature 分支的时候你的同事频繁地往 main 分支推送你需要的代码，merge 的方式会造成很多分叉，导致分支结构十分复杂和紊乱，污染你的提交历史。

但是 merge 会保留所有历史提交，不会破坏历史提交的结构，这一点在多人协作的时候很重要！

Rebase | 提交历史的线性编织

rebase 的使用方式与 merge 类似：

git checkout feature
git rebase main  

与 merge 不同的是，rebase 并不会保留原有的提交，而是会创建当前分支比目标分支更新的所有提交的副本， 在上述例子中（将 feature 变基到 main）就是 2' 和 4'，然后将 2' 和 4' 按次序插入目标分支末尾：  

这样就完成了一个 rebase 的过程（注意，这条分支是 feature 分支而不是 main 分支，原先的提交2和提交4已经被抛弃了），feature 分支实际的样子是：

你可以理解为，把 feature 分支 rebase（变基）到 main 分支的意思是：让你现在的 feature 分支基于最新的 main 分支重新开发（创建副本并且移动到末尾）

是不是很简单？  

不，一点都不简单。

rebase 有一个非常大的坑，那就是它会改变提交历史。

想象一下你和你同事都在开发 main 分支，然后在你开发的时候，你的同事突然把 main 变基了，假设你们之前是这样的：

结果现在变成了这样子：

原来的提交5直接消失了，你的分支已经跟 main 分支匹配不上了，那现在你还能正常把你的分支合入到 main 分支中吗？显然不可以。

所以，main 分支是万万不能使用 rebase 的！！！

在你打算 rebase 的时候，一定要想想是否还有别人也在开发这个分支。

适用场景

从上面的例子中不难发现，merge 和 rebase 最大的区别在于是否会保留原有的提交（或者说破坏原有的提交结构）。

merge 会对提交历史进行保留，很显然更适合多人协作开发的场景，因为如果出现问题也可以追溯到历史的每一次提交。

而 rebase 则是会让提交历史更加简洁易读，保持提交历史的线性结构，所以更适合个人开发和整理分支的情况。

如果我想要把某个特性分支 feature_xxx 合并到 main 分支中的时候，最好的方式就是 merge，而当我一个人需要开发某个 feature_xxx 分支的时候，最好的方式就是 rebase。

一句话概括就是，merge 适合团队协作，而 rebase 适合一个人开发的分支。