git rebase命令是一个神奇的git命令，初学者应该少用这个命令，但是如果你真正的了解rebase命令，那它会帮助你省去很多的麻烦。今天我们就详细的分析rebase和merge两个命令。
概述
git rebase和merge两个命令的功能是非常相识的，他们都会把一个分支上的变更合入到另一个分支中去，只是他们采用了完全不一样的设计思路。
想象一个非常常见的场景：你新建了一个feature分支，并且在这个分支上开发一个新的特性，这个时候有一个同事需要把他的commit合并到master分支上去。
常见的场景
这个时候如果合入的Master的commit需要依赖你的feature分支中的特性的时候，那么你有两个命令可以选：merge和rebase。
Merge命令
最简单的方法就是使用如下的命令把master分支的代码合并到feature分支中去：
git checkout feature
git merge master
这将在feature分支中创建一个新的“merge commit”，它将两个分支的历史联系起来，最终得到一个类似于此的分支结构：
git merge命令图解
Merge操作是一个非常好的选择，因为它是非破坏性的操作。已经存在的分支不会有任何的变化，如果需要进行回滚或者查看变更记录会非常的方便。
但是这也意味着每一次合并都需要有一个无效的“merge commit”，如果merge操作非常频繁的化，这会污染分支变更历史，会让变更历史非常的难以理解。
Rebase命令
作为merge命令的替代方案，你可以把feature分支的代码直接rebase到master分支上去。命令格式如下：
git checkout feature
git rebase master
这个命令会把feature分支直接嫁接到master末尾，从而把所有的feature上的变更都合并到master上去。和merge命令不同的是，rebase命令不会创建一ge类似与“merge commit”的提交，但是会把feature分支上的每一个commit在master分支上创建一个新的commit。
git rebase命令图解
使用rebase命令的主要好处是，你得到一个更清洁项目历史。首先，它消除了Git合并所需的不必要的合并提交。其次，你可以看到上面的图，rebase能够得到一个完美的线性项目历史。这使得它更容易与git log之类的命令来查看git commit的历史。
但是，这种操作需要有两种权衡：安全性和可追溯性。如果你不遵循Rebase命令的黄金规则，重新书写项目commit历史可能会为你的项目工作流带来灾难性的后果。
交互式的Rebase
交互式的Rebase让我们有机会把commit rebase到新的分支上去的时候，记录下rebase进来的commit信息，这会比直接rebase好上许多，因为这样知道rebase命令是在什么时候执行的，并且哪些commit被rebase到新的分支里来了。通过如下命令：
git checkout feature
git rebase -i master
这个时候会打开一个文本编辑器，并且列出了会被rebase的commit的信息。
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
Rebase命令的黄金法则
如果你对rebase有了非常清除的认识，那么最应该知道的事情是：rebase命令在什么时候不能使用。使用rebase命令的黄金法则就是：不要在公共分支中使用。
比如：你把master分支rebase到你自己的feature分支上去了，但是其他开发同学并不知道这个事情，他们还会使用之前master分支，这显然会带来很多问题的。
git rebase可能遇到的场景