（一）为啥要用 rebase 而不是 merge？

官网笔记：

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。
一句话理解 merge ：整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）。

变基（rebase）。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

变基的风险
呃，奇妙的变基也并非完美无缺，要用它得遵守一条准则：
如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。
变基操作的实质是丢弃一些现有的提交，然后相应地新建一些内容一样但实际上不同的提交。 如果你已经将提交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作，此时，如果你用 git rebase 命令重新整理了提交并再次推送，你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合，如果接下来你还要拉取并整合他们修改过的提交，事情就会变得一团糟。
这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的， 但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。

一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁——例如向某个其他人维护的项目贡献代码时。 在这种情况下，你首先在自己的分支里进行开发，当开发完成时你需要先将你的代码变基到 origin/master 上，然后再向主项目提交修改。 这样的话，该项目的维护者就不再需要进行整合工作，只需要快进合并便可。
请注意，无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。

merge 与 rebase 的不同：

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

直接上效果图：

仅用 merge：

使用 rebase ，没有了交叉：

（二）步骤

1. 先切到子分支 branch4。
2. 在 branch4 分支上 rebase master 分支，把自己的commit信息复制到master分支上。（这里有个问题，到底是 master “被改了”，还是 branch4 “被改了”？因为你在步结束后使用 git status 命令会发现，系统提示 branch 分支与远端 branch4 出现了偏差。）
   git rebase master
3. 切到 master 分支。
4. 在 master 分支上 merge branch4 分支。
   git merge branch4
5. 推送到远端。

（三）结果

发现 branch4 的东西已经合到 master 分支上了，还没有出现交叉。

（四）冲突解决

不要慌，按平常一样解决冲突即可，解决完后 git add ，但不要 git commit，用git rebase --continue即可
此时会出现vim窗口，让你修改那个变基冲突的 commit 信息。填上就行，使用 :wq 保存并退出。

1. 解决冲突
2. git add
3. git rebase --continue

这时候如果使用git status查看，会告知你落后于自己远端分支，让你使用git pull合并远程分支，此时还是老样子，忽略该信息即可。
之后走正常 rebase 流程。

（五）问题

之前提示的与远端出现偏差，这里采用的方法是直接忽略了，这意味着远端的 branch4 不会被更新，换句话说，那个分支被做遗弃处理了。改如何解决？
有一些不要使用 rebase 的场景：Git命令之不要使用rebase的场景

（六）变基也有风险

。。。

参考文章

Git命令之rebase合并分支
变基: 官方文档