先看一个实际场景

首先构造两个分支 master 和 feature分支，其中 feature 分支是基于 master 分支拉的新分支，如下图，每一个节点表示一个commit版本号，假如我们是从 master 分支的 E 版本节点拉的新分支，在feature分支上有三次新的提交，分别是A、B、C。在master分支上有两次新的提交，分别是F、G。

          A---B---C   // feature 分支/D---E---F---G     // master 分支

此时执行以下代码，变基后的版本节点会发生如下变化

	git checkout featuregit rebase master# 以上操作等价于git rebase master feature

                  A'--B'--C'   // feature 分支/D---E---F---G            // master 分支

• 官方解释：

  当执行rebase操作时，git会从两个分支的共同祖先节点开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面。

• 结合以上例子来看

  当在feature分支上执行git rebase master时，git会从master和feature的共同祖先E版本开始提取feature分支上的修改，也就是A、B、C三次提交，先提取到。然后将feature分支指向master分支的最新提交上，也就是G。最后把提取的A、B、C三次提交变基到G版本。这里需要注意，实际是会依次拿G和A、B、C内容分别比较，处理冲突后生成新的A'、B'、C'。注意，这里新的A'、B'、C'版本号和之前的A、B、C已经不一样了，是我们处理冲突后的新内容，feature指针最后也是指向C' 版本号。

• 通俗的理解

  git rebase 操作会变更我们刚开始拉取分支的基底代码版本，我们拉取新分支的原分支上有新的改动，此操作之后会把原来分支新的改动变基到我们新分支新的改动之前，注意，变更之后，新分支新的提交版本号也都会更改，生成相应新的版本号。

git rebase 过程中如何解决冲突

1. 解决冲突后保存
2. 执行git add . 命令
   3.执行 git rebase --continue 命令 // 注意add之后不是使用commit命令

如果 rebase 过程中，想中途退出，恢复 rebase 前的代码则可以用以下命令

git rebase --abort。

git rebase 的优缺点

• 优点：提交记录会比较简洁
• 缺点：无法区分当前分支最早是从哪个分支拉出来的，如果用在主分支上，其他开发人员想看主分支的历史，却无法查看原来的历史了，因为历史已经被篡改了。出现问题不易追溯。

注意：因为有以上缺点，有些公司其实会禁用rebase，不管是拉取代码还是合并代码，统一都使用merge，虽然会多出一条无意义的merge记录，但能非常清楚地知道主分支的代码合并记录以及合代码的时间顺序。