描述

rebase的使用场景就是让提交记录变得简洁。有如下三个场景。

场景1

把多个提交记录合并成进行`push`。比如项目开发时间较长，你`commit`了多次(还没有push到远程仓库)，分别是v1、v2、v3、v4四个版本；想`push`的时候在记录上只显示一次或者把某几次的提交合并成一次，这时就可以通过rebase实现。

// 先查看本地的提交记录

// 可以看到v1、v2、v3、v4的commitId

git log

// 从指定的commitId到最近的提交进行合并，比如commitId是V2的，那V2到V4的会进行合并

git rebase i commitId

// 第二种写法,把最近的三次提交进行合并(中间是个波浪号)

git rebase i HEAD~3

执行上面的命令后，就出现上面的界面，把要合并的几次提交的message都列举了出来，但`message`前面有一个`pick`的关键字。通过下面的注释中的讲解可以知道`pick`是`commit`的意思。

我们需要把v3和v4的pick改成s，也就是squash，就是把下面一条和上面一条进行合并提交。这样就是v4和v3合并，v3和v2合并，最后只有一条提交记录。

`wq`退出`base`的时候会再转到一个commit信息的界面，这时就会把上面三次的提交记录都列举出来，并且可以修改，再`wq`进行退出合并就完成了。

这是再`git log`查看提交记录，就只剩两次了，第一次和刚才合并的那次。

注意事项

>上面的操作只限于没有push到远程仓库，只是本地提交，如果已经push到远程仓库的，也可以这样做，但会更麻烦。

场景2

把多个分支的提交改变成只有一条提交线。

项目开发通常是多人多分支进行，因此在合并到master后，会发现有很多拉取的分支及提交记录，有些人可能会觉的这样不简洁，所以想只有一条提交线。

比如master和dev分支，master有v1,v2两次提交，从v2拉取了dev分支并且开发了v3，期间master有v4的提交，当把dev合并到master时，会需要先从master上拉取v4，然后和dev进行合并再提交。*这样会多出一次合并代码的提交，并且git的提交图形是常见的那种多分支的状态。*

有的人可能为了所谓的简洁，所以觉的上面的两种现象不好，所以就想通过rebase显示成一条线。步骤如下:

// 本地提交dev的代码,在dev分支上变基

// 下面的命令会把master的代码拉取到dev分支上，并变基，也已经合并了

git rebase master

// 切换到master，合并dev

git checkout master

git merge dev

上面操作过后，再看log就会发现是V1，V2，V4，V3；注意，即使V3的创建和提交时间都在V4之前，在进行变基的时候，也会放在master上已有提交之后。

缺点

比较难看出来提交是从哪个分支来的、什么时候创建，只有一个提交时间。分支也不知道是从什么时候创建的，简洁是牺牲详细的记录换来的。

场景3

比如在公司开发了一个功能提交了V1,但是没有push到远程仓库。回到家又在分支上开发了V2，然后提交到云仓库。

因为v1没push，所以v2上是没有v1的东西，这时如果在公司可以pull到v2的代码进行合并，但是这样就会出现分叉，并多出一次合并记录，也就是场景2的问题。

操作

// 使用fetch不要使用pull，pull是fetch和merge的合并操作

git fetch origin dev

git rebase origin/dev

rebase冲突解决

在rebase的时候如果发生冲突。先解决冲突，然后`git add`把文件添加，无需执行git commit，然后执行`git rebase --continue`就行了。

git pull --rabase