rebase和merge的区别详解

引言

当你正在开发一个新的功能，准备合并回主分支时，可能会发现存在很多冲突。此时究竟应该用合并还是变基呢？

合并（merge）

一个典型的例子是，从节点A开始，团队开发了B和C功能并合并到了主分支，而你在一个特性分支开发了D和F。执行git checkout main命令切换到主分支后，再运行git merge feature将特性分支合并进来。此时，git会创建一个新的提交$\hat{E}$，它将两个分支合并在一起，不对现有提交做任何改动，仅增加一个合并提交声明，此处已将特性分支和主分支合并到一起。这种情况下，原始的分支结构以及所有提交原数据（包括时间戳、作者信息等）都会被完整保留。

合并虽然保留了所有信息，但是运行git log --oneline --graph命令时，会看到分支和合并点交织成的树状结构，很难理清谁在什么时间做了什么事，以及为什么这么做。此外，还可能看到重复的提交记录、合并噪音或者顺序错乱的提交。

变基（rebase）

使用变基可以让所有提交呈直线，易读、易二分、易调试。但是会付出重写提交历史的代价，在共享分支中可能不安全。

执行git checkout feature命令切换到feature分支，然后运行git rebase main命令将feature变基到main分支上。此时，git会在C提交点之上，将D和E提交作为新的提交重新应用，此时版本提交记录显示为：A->B->C->D->E，形成一条直线型提交记录。这样做的话，git会创建新的提交记录，而不会复用原有的提交。因此，尽管代码内容可能相同，但经过变基后的提交记录依次是：A->B->C->$\hat{D}$->$\hat{E}$。$\hat{D}$和$\hat{E}$使用的是新ID，从技术角度看，原始的D和E已不在属于主历史线。