git rebase
该命令同git merge解决的问题一样，这两个命令都是将改动从一个分支整合到另一个分支，但是实现方式不同。
例如：
developer在一个特定分支（Feature）上开发新功能，此时另一个小伙伴提交了一个新的commit更新了master分支，此时会导致分支分叉的历史记录，如果我们工作中使用git，那么应该都会遇到这种情况。git分支图如下：
此时，如果你的开发分支需要基于master最新的commit进行开发，有两个选择：merge或者rebase。
merge
git checkout feature
git merge master
or
git merge feature master
这样会在feature分支创建一个新的commit，然后将两个分支的历史合并，git分支图如下：
merging是一个没有破坏性的操作，已存在的分支结构不会被改变。
每次合并上游的改变时，feature分支会有一个额外的merge commit。如果master分支非常活跃，这样feature分支会有很多历史commit。
rebase
另外一种方法是使用rebase：
git checkout feature
git rebase master
以上命令将所有的feature分支的改动移动到了master分支上，rebasing重写了项目的历史，而不是新创建一个merge commit。git分支图如下：
rebasing的优点是项目的历史会更加整洁。首先，它消除了不必要的merge commit，其次rebasing会让项目的分支呈线性，我们可以根据git log追溯项目的历史改动。
interactive rebasing
命令如下：
git checkout feature
git rebase -i master
此时会出现文本编辑界面，列出了所有commit的信息：
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
你可以对该文本进行编辑，例如如果commit#2仅仅在#1基础上修复了小功能，那么可以将文本修改为：
pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
当你关闭该文本时，git会按照你的指示执行，rebase之后分支图如下：
消除不重要的commit，自定义的调整项目历史。
rebasing的黄金法则
理解了rebasing之后，需要知道什么时候一定不要使用它。
绝不要在公共分支使用rebasing！！！
