git rebase作用：相对于git merge的第二种合并分支方法，但是git rebase可以使git提交变得整洁
1. 场景1——合并多次提交
在日常开发中，代码变更比较频繁，有时候想让前几次提交的合并为一次提交，这里可以使用git rebase -i 命令来完成。
命令格式：git rebase -i [startpoint] [endpoint]
-
其中
i表示interactive的缩写即弹出交互式的界面让用户编辑完成合并操作； -
[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)
执行完命令后，会跳到一个vim编辑器中：
- pick：保留该commit（缩写:p）
- reword：保留该commit，但我需要修改该commit的注释（缩写:r）
- edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
- squash：将该commit和前一个commit合并（缩写:s）
- fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
- exec：执行shell命令（缩写:x）
- drop：我要丢弃该commit（缩写:d）
注意: 不要把已经在仓库的commit进行合并，避免冲突造成不必要的麻烦
2. 场景2——线性提交记录
参考文章：http://blog.itblood.com/1646.html
rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。
Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。
-
创建新分支 bugFix分支：
git branch bugFix -
提交一次(提交在master分支上)：
git commit -
切换到bugFix分支：
git checkout bugFix -
提交一次（提交在bugFix分支上）：
git commit -
使用git rebase把 bugFix 分支里的工作直接移到 master 分支上（移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的）：
git rebase master
注意：提交记录 C3 依然存在（树上那个半透明的节点），而 C3’是我们 Rebase 到 master 分支上的 C3 的副本。
- 切换到master分支上（为了进行更新master的操作）：
git checkout master
把master的 rebase 到 bugFix 分支上（由于 bugFix 继承自 master，所以 git 只是简单的把 master 分支的引用向前移动了一下而已）：git rebase bugFix