git专题 | git merge的fast-forward和no-fast-forward模式有什么区别

在上一篇git专题 | 脱离IDE，git在命令行是如何工作的主要讲了如何在命令行中使用 git，将变更信息添加到暂存区以及提交到本地仓库。之后又结合 branch 分支，分析了 git 中各个工作区域的作用。其中，在讲到 branch 的时候，我创建了 dev 分支，做了变更。

在实际开发中，分支是为了方便团队成员在不同的分支进行开发。最终我们需要将这些代码集成到主分支（master），git merge 通过将一个分支的改动合并到另一个分支。

这里我在 master 分支创建一个名为 aqi 的文件，先写入1，然后 add、commit 提交到本地仓库，然后分两次分别写入2和3，执行上述操作。在整个过程中，文件 aqi 一共被 commit 提交了三次，也就是有三次提交记录。

然后在此基础上，创建 dev 分支，这时候的 dev 分支就像是 master 分支的“镜像”，两个分支具有相同文件内容以及提交记录。

如果 master 分支不做任何变更，这时候我在 dev 变更 aqi 文件的内容，新增一行4，然后提交到本地仓库。

在可视化界面中可以看到 dev 分支基于是基于 master 的第三次提交进行的变更。

这时候切换到 master 分支合并 dev 分支的变更。

代码语言：bash复制

git merge dev

这样 dev 分支的变更就被合并到 master 分支上了。

fast-forward 是快进模式，当你当前的分支没有任何新的提交，而另一个分支包含了一些新提交时，Git 会直接将当前分支快进到目标分支的最新提交，而不创建额外的合并提交。这种合并方式不会产生新的提交，分支历史仍然是线性的。

例如在上面的提交记录中，master 是 1、2、3，dev 的是 1、2、3、dev4。dev 是全包含于 master 的，所以这里使用的就是快进模式。

从上图可以看到，提示中有 fast-forward，表示直接将两个分支合并，不创建新的 commit，移动两个分支的指针指向 dev 的 commit，此时 dev 的 commit 属于两个分支。

通过 git log 查看提交日志，master 分支已经有了 dev 之前的提交信息。这里要注意的是，master 分支直接使用了 dev 分支的提交信息。

在可视化界面中也可以印证这一点，这时候 master 分支的 HEAD 指向 dev4 这个提交信息。

我们一共有两种方式来使用 no-fast-forward模式：

我们在来看看 no-fast-forward 模式下，git merge 是如何合并分支的，这里我先使用 git reset 将 master 分支恢复到合并前的状态。

此时 master 分支只有3个提交信息，dev 是4个。使用 --no-ff 指定 no-fast-forward 模式合并分支。

代码语言：bash复制

 git merge dev -m'master4' --no-ff

我们知道 -m 是 commit 时，用来指定提交信息的参数。这里在合并之后，使用 git log 查看提交日志，除了有 dev4 这个提交信息，也多了上面命令指定的commit信息。

也就是说，在 --no-ff 模式下，当前分支合并之后会新建一个commit。我们可以查看可视化提交信息来理解。

如图，这里 master 分支的 HEAD 不再指向 dev4，而是指向合并后新建的commit。

我在 master 分支上，基于提交3创建了一个文件作为新变更（修改同一文件会冲突），然后提交信息为 master4。

如图所示，master 和 dev 分支都有共同的祖先，都基于3节点做了新的变更提交。这里执行 git merge dev 合并分支。

如图所示，和指定 --no-ff 相同，都创建了新的提交信息。

本篇文章主要讲述了 git merge 两个模式下，是如何合并分支的。fast-forward 适用于一个分支全包含于另一个分支的场景，分支合并后会使用被合并分支的提交信息，而 no-fast-forward 会重新生成一个新的合并提交信息。

在 git 合并分支操作中，除了 merge 还有 rebase，这两个有什么区别，在下篇文章会继续探讨。

1 人点赞