git rebase

该命令同git merge解决的问题一样，这两个命令都是将改动从一个分支整合到另一个分支，但是实现方式不同。

例如：

developer在一个特定分支（Feature）上开发新功能，此时另一个小伙伴提交了一个新的commit更新了master分支，此时会导致分支分叉的历史记录，如果我们工作中使用git，那么应该都会遇到这种情况。git分支图如下：

git branch

此时，如果你的开发分支需要基于master最新的commit进行开发，有两个选择：merge或者rebase。

merge

git checkout feature

git merge master

or

git merge feature master

这样会在feature分支创建一个新的commit，然后将两个分支的历史合并，git分支图如下：

* merge commit

merging是一个没有破坏性的操作，已存在的分支结构不会被改变。

每次合并上游的改变时，feature分支会有一个额外的merge commit。如果master分支非常活跃，这样feature分支会有很多历史commit。

rebase

另外一种方法是使用rebase：

git checkout feature

git rebase master

以上命令将所有的feature分支的改动移动到了master分支上，rebasing重写了项目的历史，而不是新创建一个merge commit。git分支图如下：

* brand new commit

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之后分支图如下：

* brand new commit

消除不重要的commit，自定义的调整项目历史。

rebasing的黄金法则

理解了rebasing之后，需要知道什么时候一定不要使用它。

绝不要在公共分支使用rebasing！！！