1. 分支变基（ Git Rebase ）

git rebase 能实现和 git merge 同样的功能，它可以以另一种方式来实现「分支合并」的效果。

1.1 merge 和 rebase

假设我们有两个分支（ master 和 feature ）。feature 是基于 master 的 C1 节点建立的分支，然后开发人员分别在两个分支各自开发：

一个人在 C1 版本基础上开发出了 C2 版本；另一个人在 C1 基础上开发出了 C3 版本。

merge 命令

现在我们想要把 feature 分支开发的内容合并到 master，使用 merge 命令：

$ git checkout master
$ git merge feature

复习

merge 命令的使用是「站在 master 分支」的角度上来看，将 feature 分支的内容「纳入」到 master 分支。master 分支会演进出一个新的版本。

从整体来看，merge 命令执行之后，会在之前的相关的 3 个版本节点之外生成一个新的节点 这个新节点将会是 master 线路上的最新的「终点」。

rebase 命令

对于同样的初始情况，如果我们使用 rebase 命令会有什么不同。

git rebase 的正确使用方式和 git merge 有一点是完全相反的：

• 使用 git merge 时，你是站在 A 分支，考虑把 B 分支「合并进来」；
• 使用 git rebase 时，你是站在 B 分支，考虑把 B 分支的「基」变成 A 的某个节点（通常是端点，即，最新的节点）。

你要执行的命令如下（再次强调，你是站在 feature 分支上）：

$ git checkout feature
$ git rebase master

在 GitKraken 中等价的操作如下：

执行 git rebase 的前后差异如下：

1.2 后续操作

虽然经过 git rebase ，feature 分支上已经含有了 master 分支和自己的所有的变更，但是通常这些代码最终是要合并到 master 分支上的，即，逻辑上 git rebase 并非一系列操作的「终点」，而是「中点」。

所以，最后我们还要回到 master 分支上，执行一次 git merge 操作，将 feature 分支合并进 master 分支。（再啰嗦一边，合并的时候，你是站在 A 分支，把 B 分支合进来、合进来、合进来。什么叫合进来？）

整个流程的总而言之一句话

feature rebase on master, master merge feature.

2. 关于压缩提交

git rebase 名了除了用于「另一种」的合并之外，还有一种常见用途就是用来压缩提交记录。学名叫交互式变基（ Interactive Rebase ）。

效果看起来挺明显、挺直观的：

注意

变基和交互式变基底层原理是一样的，但是表现出来的功效却差的有点远。

一般而言，都是把它俩当作两个独立地、不相关地功能。

---

有这种使用场景也很常见：有时你以为你的有一次提交完成了所有工作，但是最后的结果却是你随后陆陆续续还要再补充几次提交才算是完成了原计划的一项任务。

这种情况下，你在 Git 的提交记录中将留下多个历史版本。而实际上，这多个版本并无存在的必要，逻辑上，只需要有一个就行了。

理想情况下，你可以用 git rebase -i 命令把多个 Commit 压缩成一个。