我使用'git rebase'，它起作用了。

当您尝试合并一个提交和一个可以通过跟踪第一个提交的历史记录而到达的提交时，Git通过向前移动指针来简化事情，因为没有任何分散的工作要合并在一起——这被称为“快进”。

更多信息请参见3.2 Git分支-基本分支和合并

另一方面，

如果master没有分叉，Git不会创建一个新的提交，而是将master指向特性分支的最新提交。这是一个“快进”。

在快进合并中不会有任何“合并提交”。

在Git中，“快进”意味着以这样一种方式更新HEAD指针，即它的新值是先前值的直接后代。换句话说，先验值是父(parent)、祖父母(grandparents)、祖父母(grandgrandparent)……

Fast forwarding is not possible when the new HEAD is in a diverged state relative to the stream you want to integrate. For instance, you are on master and have local commits, and git fetch has brought new upstream commits into origin/master. The branch now diverges from its upstream and cannot be fast forwarded: your master HEAD commit is not an ancestor of origin/master HEAD. To simply reset master to the value of origin/master would discard your local commits. The situation requires a rebase or merge.

如果你的本地master没有变化，那么它可以被快速转发:简单地更新为指向与最新的origin/master相同的提交。通常，快进不需要特别的步骤;在没有本地提交的情况下，可以通过合并或重基来完成。

是否可以假设快进意味着所有提交都在目标分支上重播，并且HEAD设置为该分支上的最后一次提交?

不，这被称为重基，其中快进是一种特殊情况，当没有要重放的提交时(目标分支有新的提交，目标分支的历史没有被重写，因此目标分支上的所有提交都以当前的提交作为它们的祖先)。

我使用'git rebase'，它起作用了。

想象有一根树枝

主人:A——> B——>

它上有两个提交，A和B 还有另一个特性分支，来自B，它有以下提交历史

特征:C——>D---->E

现在是这样的

`A--->B`
     `C--->D--->E `

所以当你想要合并它的时候，你可以通过快进合并来完成通过将头部从B移到E并将特征分支合并到主分支中它看起来是这样的

A——>B——>C——>D——>E，标题在E。

Atlassian的这个例子非常好:

Atlassian例子

但正如示例中提到的，这只在分支没有分叉的情况下才有可能，在这种情况下，传统的merge或——no-ff可以工作。

另一个好例子