原文：https://www.atlassian.com/git/tutorials/merging-vs-rebasing
参考：https://github.com/geeeeeeeeek/git-recipes/wiki/1.1-%E6%9E%9C%E5%A3%B3%E4%B8%AD%E7%9A%84-Git
概述
首先我们要明白的是 merge和 rebase 设计来的目的都是将修改从一个分支合并到另一个分支，它们只是采取了不同的方式而已。
想想当你在master分支上check出来的功能分支中处理功能时，另一个团队成员使用新提交更新master分支这会导致分叉历史记录，对于使用Git作为协作工具的任何人来说都应该很熟悉。现在，如果master中心的提交和你的开发的内容是相关的，为了将新的提交合并到功能分支中，你有两个选择：merge或者rebase.
merge：
将master分支合并到你新功能分支的最简单方式就是使用类似下面的命令：
git checkout feature
git merge master
feature分支中新的合并提交（merge commit）将两个分支的历史结合在一起，这时候的分支结构如下：
merge好在它是一个安全的操作，现有的分支不会被更改，这也避免了rebase的缺点。
另一方面，这同样意味着每次合并上游的更改时，feature分支都会引入一个外来的合并提交。如果master分支非常活跃，这会多少污染你的历史分支。还是会增加理解项目历史的难度。
rebase:
作为merge的替代选择，你可以像下面这样将feature分支并入到master分支：
git checkout feature
git rebase master
它会把整个feature分支移动到master分支的后面，有效的把所有master分支上新的提交并入过来，但是，rebase为原来分支上每一个提交创建了一个新的提交，重写了项目历史，并且不会带来合并提交。
rebase最大的好处就是你的项目历史会非常干净，首先它不像git merge那样引入不必要的合并提交，其次，rebase导致最后的项目历史也一样呈现出完美线性。你可以从终点到起点，不需要浏览任何的fork。不过这种简单的提交历史会带来两个后果，安全性和跟踪性。如果违反了rebase的黄金法则，重新项目历史可能会给协作工作流带来灾难性影响。rebase中也不会有合并提交中附带的信息，你看不到feature分支中并入了上游的哪些更改。
Rebase黄金法则：
当你理解rebase是什么的时候，最重要的就是什么时候不能用rebase,git rebase的黄金法则就是不要在公共分支上使用。
例如，你可以想象一下当你把master分支并入到你的功能分支会发生什么：
rebase会把master上所有的提交都移到了你的功能分支后面，这样的问题就是它只发生在你的代码库中，其他开发人员依然在他们落后master分支上，因为rebase造成了新的提交，git会认为你的master分支和别人的master已经分叉了。
同步两个master分支的唯一办法就是将他们merge在一起，造成了一个额外的合并提交和两堆包含同样更改的提交，不用说，这会让人非常困惑。
所以，在你使用rebase之前，一定要问问自己（有没有人在这个分支上工作），如果有，那你就不要继续操作，重新找到一个无害的方式（例如 git revert）来提交代码，否则，你可以随心所欲的重写历史。
