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

什么是快进?

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

给定以下分支设置:

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

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

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

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

什么时候没有快进?

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

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

——no-ff标志阻止git merge执行“快进”，如果它检测到你当前的HEAD是你试图合并的提交的祖先。快进是指git不构造合并提交，而是将分支指针指向传入的提交。这通常发生在没有任何本地更改的情况下进行git拉取时。

然而，有时你想防止这种行为发生，通常是因为你想维护一个特定的分支拓扑(例如，你正在合并一个主题分支，你想确保它在读取历史记录时看起来是那样的)。为了做到这一点，你可以传递——no-ff标志，git merge将始终构造一个merge而不是快进。

类似地，如果你想执行git pull或使用git merge来显式快进，如果不能快进，你想退出，那么你可以使用——ff-only标志。这样你就可以不假思索地定期执行git pull—ff-only之类的操作，然后如果它出错，你就可以返回并决定是合并还是重基。

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

合并策略

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

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

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

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

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