Rebase 的一种使用场景：分支合并
1.我们先从 master 分支切出一个 dev 分支，进行开发：
git:(master) git checkout -b feature1
2.这时候，你的同事完成了一次 hotfix ，并合并入了 master 分支，此时 master 已经领先于你的 feature1 分支了：
3.恰巧，我们想要同步 master 分支的改动，首先想到了 merge ，执行：
git:(feature1) git merge master
4. git:(feature1) git log
就会在记录里发现一些 merge 的信息，但是我们觉得这样污染了 commit 记录，想要保持一份干净的 commit ，怎么办呢？这时候， git rebase 就派上用场了。
5.使用 rebase 后来看看结果：
git:(feature1) git rebase master
首先， git 会把 feature1 分支里面的每个 commit 取消掉；
其次，把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
然后，把 feature1 分支更新到最新的 master 分支；
最后，把上面保存的 patch 文件应用到 feature1 分支上；
从 commit 记录我们可以看出来， feature1 分支是基于 hotfix 合并后的 master ，自然而然的成为了最领先的分支，而且没有 merge 的 commit 记录，是不是感觉很舒服了。
6.在 rebase 的过程中，也许会出现冲突 conflict 。在这种情况， git 会停止 rebase 并会让你去解决冲突。在解决完冲突后，用 git add 命令去更新这些内容。
注意，你无需执行 git-commit，只要执行 continue
git rebase –continue
7.在任何时候，我们都可以用 –abort 参数来终止 rebase 的行动，并且分支会回到 rebase 开始前的状态。
git rebase —abort
合并多次提交纪录
1. 设想一下，你要做 code review ，结果一个很小的功能，提交了 60 多次，会不会有一些崩溃？
2. 会造成分支污染
你的项目充满了无用的 commit 纪录，如果有一天线上出现了紧急问题，你需要回滚代码，却发现海量的 commit 需要一条条来看。
3. 基于上面所说问题，我们不难想到：每一次功能开发， 对多个 commit 进行合并处理。
- 1.我们来合并最近的 4 次提交纪录，执行：
- git rebase -i HEAD~4
- git rebase -i ad90262ee7c94a6ade58ac7fd96ab // 合并此hash 之前的 记录
- 2.这时候，会自动进入 vi 编辑模式：
- 按照如上命令来修改你的提交纪录：
- 一般第一用pick， 其余用squash
- 3.如果保存的时候，你碰到了这个错误：
- error: cannot ‘squash’ without a previous commit
- 注意不要合并已push的东西，也就是已经提交远程分支的纪录。
- 4.如果你异常退出了 vi 窗口，不要紧张：
- git rebase –edit-todo
- 这时候会一直处在这个编辑的模式里，我们可以回去继续编辑，修改完保存一下：
- git rebase –continue
- 5.查看结果 git log
- 三次提交合并成了一次，减少了无用的提交信息。
- 6 pull request 中出现多次提交，可以先合并然后强推 git push -f
git rebase 与merge 区别
rebase 会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
merge 会把公共分支和你当前的commit 合并在一起，形成一个新的 commit 提交
注意：
- 不要在公共分支使用rebase
- 主分支上用rebase 会使主分支的提交被篡改，因为rebase 其他分支提交插进来 ，主分支之前的提交就放到了后面
- 本地和远端对应同一条分支,优先使用rebase,而不是merge