这是一个老问题，在其他文章中也有一些微妙的提及，但对我来说，这个问题的解释是，非快进合并将需要单独的提交。

合并策略

显式合并(又名非快进):创建一个新的合并提交。(这是你使用no-ff后得到的结果。)

快速向前合并:快速向前，不创建新的提交:

Rebase:建立一个新的基准面:

Squash:用力压碎或挤压(某物)使其变平:

这是一个老问题，在其他文章中也有一些微妙的提及，但对我来说，这个问题的解释是，非快进合并将需要单独的提交。

什么是快进?

快进是指在签出的分支之前对分支进行合并或重基时Git所做的事情。

给定以下分支设置:

两个分支都引用了同一个提交。他们有着完全相同的历史。现在提交一些特性。

主分支仍然引用7ddac6c，而该特性已经向前提交了两次。现在可以将特性分支考虑在主分支之前。

现在相对容易看到Git执行快进时会发生什么。它只是更新主分支以引用该特性所做的提交。没有对存储库本身进行任何更改，因为来自特性的提交已经包含了所有必要的更改。

你的存储库历史现在看起来是这样的:

什么时候没有快进?

当在原始分支和新分支中进行更改时，不会发生快进。

如果您要将特性合并或重新建立到master上，Git将无法进行快进，因为这两棵树都发散了。考虑到Git的提交是不可变的，Git没有办法在不改变父引用的情况下将提交从特性转换到主特性。

——no-ff选项确保不会发生快速向前合并，并且总是会创建一个新的提交对象。如果您希望git维护特性分支的历史记录，这可能是可取的。              在上图中，左侧是使用git merge -no-ff后的git历史记录，右侧是使用git merge的示例，其中ff合并是可能的。

编辑:此图像的以前版本仅指示合并提交的单个父节点。合并提交有多个父提交，git用它们来维护“特性分支”和原始分支的历史记录。多个父链接用绿色突出显示。

——no-ff标志导致合并总是创建一个新的提交对象，即使合并可以用快进执行。这避免了丢失关于特性分支的历史存在信息，并将所有添加了该特性的提交组合在一起