入职后第一次提交review，由于一个功能中途有修改提交了三次commit，然后我就发起了三次review。。mentor说你rebase一下，合并成一次提交记录。表面淡定内心懵逼的我赶紧Google了一下，补充一下知识点。
合并多次提交记录
场景大家都知道了，它的目的一个是有利于code review；还有就是让commit记录更加美观，万一哪天需要回滚代码，也不至于太抓瞎。
接下来就看看如何操作吧～
我们来合并最近三次的提交记录。
- 查看提交历史，git log
首先确定要合并哪几个commit，先查看历史提交记录，例如最近4条
git log --oneline -4
17d4132e34 xxx
36fb1c5194 xxx
6eef030837 xxx
222cffedee xxx
- git rebase
想要合并前3条，有两个方法
- 指明要合并的版本之前的版本
// 要合并前三条，就指定第三条之前的版本也就是第四条
git rebase -i 222cffedee
- 从HEAD版本开始往前数3个版本
git rebase -i HEAD~3
- 选取要合并的提交
执行了上面的命令后，会自动进入 vi 编辑模式，头几行如下
pick 17d4132e34 '注释**********'
pick 36fb1c5194 '注释*********'
pick 6eef030837 '注释**********'
将pick改为squash或s，之后保存并关闭文本编辑窗口即可。
pick 17d4132e34 '注释**********'
// 将这一条合并到17d4132e34上面，最终合并为一条
s 36fb1c5194 '注释*********'
// 将这一条合并到36fb1c5194上面
s 6eef030837 '注释**********'
- 查看结果
再用git log 查看一下就会发现三次合并成了一次
rebase-commit.png
可以在Learn Git Branching这个网站中照图片中的命令操作一下，更直观哦～
分支合并
某天，我和mentor各自基于dev分支拉了分支进行开发，大概从上午到了下午，mentor跟我说，你rebase一下dev分支我提交了代码你得看点东西。咋个回事？又rebase，跟上次情况不一样啊。再去Google吧。
了解了之后发现这个跟merge的功能差不多呀，但是merge会产生一些merge的记录，污染commit记录。想保持干净的commit记录，git rebase就上场啦。
还是来形象的看一下rebase的功能：
rebase-branch.png
上图中执行了git rebase master之后，dev分支是基于最新的master分支。
rebase做了什么操作呢？
- git 会把 dev 分支里面的每个 commit 取消掉；
- 把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
- 把 dev 分支更新到最新的 master 分支；
- 把上面保存的 patch 文件应用到 dev 分支上；
在 rebase 的过程中，也许会出现冲突。在这种情况，git 会停止 rebase 并会让你去解决冲突。在解决完冲突后，再执行以下命令
// 更新内容
git add .
// git 会继续应用余下的 patch 补丁文件
git rebase --continue
小伙伴们，你get了吗？
