为什么要学会git rebase？

Git无疑现在已经成为最流行的代码管理工具之一。。首先我们看下面这个图，如果仅会用git merge，那么查看git graph就会出现下图上半部分的图，而配合git rebase就会得到下图中下半部分的图，很清晰。在继续深入探讨之前，我先抛出我的观点。如果你想拥有一套稳定的，健壮的代码, 永远要使用rebase。不为别的，就为了rebase可以给你提供一套清晰的代码历史。相反的, merge会给你一套乱七八糟的代码历史。当你看到这样的代码历史的时候，我相信你绝对没有心情去研究每一个历史对应的代码。

变基的基本操作

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。 在本节中我们将学习什么是“变基”，怎样使用“变基”，并将展示该操作的惊艳之处，以及指出在何种情况下你应避免使用它。

开发任务分叉到两个不同分支，又各自提交了更新。

最容易的方法是 merge 命令。 它会把两个分支的最新快照（ C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）。

其实，还有一种方法：你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上再应用一次。 在 Git 中，这种操作就叫做 变基。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

它的原理是首先找到这两个分支的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。

现在回到 master 分支，进行一次快进合并。

此时，C4' 指向的快照就和上面使用 merge 命令的例子中 C5 指向的快照一模一样了。 这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是先后串行的一样，提交历史是一条直线没有分叉。

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

总结：选择 merge 还是 rebase？

merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容

merge 和 rebase 还有很多强大的选项，可以使用 git help <command> 查看

最后：一些注意点

• 当有修改未 commit 时，不能进行 rebase 操作，此时可以考虑先用 git stash 命令暂存
• rebase 操作会丢弃当前分支已提交的 commit，故不要在已经 push 到远程，和其他人正在协作开发的分支上执行 rebase 操作
• 与远程仓库同步时，使用 pull 命令默认进行了 git fetch + git merge --no-ff 两个操作，可以通过加上 --rebase 命令将 fetch 后的 merge 操作改为 rebase 操作，或者仅仅 'git fetch remoteName',然后才思考采取哪种整合策略 git merge(or rebase) origin/master

参考：

https://www.4e00.com/git-zh/1-git-branching.html#_rebasing

https://www.jianshu.com/p/c17472d704a0