一文带你读懂Git中的rebase与fast-forward

在项目开发的过程中，git作为版本管理工具重要性不言而喻。平常大家肯定会使用merge命令来合并分支。然而merge来合并分支有个缺点，就是当分支太多，合并太多，那么提交记录的图谱看起来就非常丑。

以上，而rebase就可以解决这个问题。下文我将使用git官方的例子来解释一下rebase与fast-forward在实际中的应用。

假设我们有一下的场景：

1. 存在一个git版本库，当前仅有master一个分支
2. 现在有一个bug需要修复，那么需要创建一个新的分支，比如叫iss53
3. 突然发现一个线上的紧急bug，需要切回master分支，并再次创建一个用于修复紧急bug的分支hotfix

下面用图片来形象的描述一下：

初始状态：

创建新的分支

$ git checkout -b iss53
Switched to a new branch "iss53"

编辑了新分支

$ vim index.html
$ git commit -a -m 'Create new footer [issue 53]'

因修复紧急bug，创建新分支hotfix

$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m '修复紧急bug'
[hotfix 1fb7853] 修复紧急bug
 1 file changed, 2 insertions(+)

下面重头戏来了。我们知道如果要上线这个紧急bug，需要将hotfix分支合并回master。

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

可以看到，合并的过程已经发生了fast-forward。我们可以简单的这样理解：当hotfix分支是基于master最新的提交进行开发的时候，就会发生fast-forward。
究其原因，因为git合并分支需要有一次新的提交（可以看后边继续的例子）。然而当git发现，像上边的情况，产生新的提交没有意义的时候（因为hotfix就是基于master最新的提交），这时候就会自动触发fast-forward。
当然你可以禁止fast-forward。即在合并的时候指明--no-ff的参数，那么无论如何都将会产生一次新的提交。

接下来，紧急bug已经修复了，我们继续切回到iss53来修改代码，并最终提交。

如上图，此时hotfix分支没用了，被删除了。接下来再次把iss53合并到master。

$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html |    1 +
1 file changed, 1 insertion(+)

值得注意是，这次是没有发生fast-forward。因为iss53并不是基于master的最新一次提交。二者合并的时候理应产生一个新的合并的提交，即下图中的C6。

现在。我们回到开始的问题。这样做会导致将来的图谱太丑。其实解决方法也很简单，只要让C3从指向c2变成指向c4即可。也就是指向master分支的最新一次提交。而这个操作就是rebase。

rebase之后，再进行合并就是触发fast-forward，也就是不会真的合并产生一个提交。

$ git rebase master
Successfully rebased and updated refs/heads/iss53.

最后再次合并iss53至master。你就可以发现图谱就会很干净了。

参考：

git官方手册