git rebase 合并提交

需求
共五次提交，要合并后三次提交只留下三次提交

使用命令行

git rebase -i HEAD~3

-i 进入交互操作界面

选择最前边的一次用pick，其他的用squash

合并成功，三次提交被合并到一次

使用vscode gitlens

合并最后三次提交把鼠标放到多一步的地方。

squash合并所有要合并的提交

合并后的message可以修改

四、Rebase 场景二：分支合并

1.我们先从 master 分支切出一个 dev 分支，进行开发：

| git:(master) git checkout -b feature1

| | —- |

2.这时候，你的同事完成了一次 hotfix，并合并入了 master 分支，此时 master 已经领先于你的 feature1 分支了：

3.恰巧，我们想要同步 master 分支的改动，首先想到了 merge，执行：

| git:(feature1) git merge master

| | —- |

图中绿色的点就是我们合并之后的结果，执行：

| git:(feature1) git log

| | —- |

就会在记录里发现一些 merge 的信息，但是我们觉得这样污染了 commit 记录，想要保持一份干净的 commit，怎么办呢？这时候，git rebase 就派上用场了。
4.让我们来试试 git rebase ，先回退到同事 hotfix 后合并 master 的步骤：

5.使用 rebase 后来看看结果：

| git:(feature1) git rebase master

| | —- |

这里补充一点：rebase 做了什么操作呢？
首先，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

| | —- |

这样 git 会继续应用余下的 patch 补丁文件。
7.在任何时候，我们都可以用 —abort 参数来终止 rebase 的行动，并且分支会回到 rebase 开始前的状态。