在 Git 中，"fast-forward" 和 "non-fast-forward" 是与分支合并相关的概念。

当你尝试将一个分支合并到另一个分支时，如果两个分支之间的提交历史是线性的（即没有另外的分支从中分叉或合并），那么这个合并就被称为 "fast-forward" 合并。在这种情况下，Git 可以简单地将目标分支指向源分支的最新提交，并且不需要创建新的合并提交。

例如，假设你有两个分支：master 和 feature。当前 master 指向提交 A，而 feature 指向提交 B，其中 B 是由 A 衍生出来的。现在你想将 feature 分支合并到 master 分支中。由于 B 的提交历史是线性的，Git 可以简单地将 master 分支指向 B，而不需要进行任何额外的操作。这就是一个 "fast-forward" 合并。

相反，如果两个分支之间的提交历史不是线性的（即它们之间有另外的分支从中分叉或合并），那么这个合并就被称为 "non-fast-forward" 合并。在这种情况下，Git 必须创建一个新的合并提交，该提交包含两个分支的全部更改内容。

例如，假设你有两个分支：master 和 feature。当前 master 指向提交 A，而 feature 由从 A 衍生出的两个提交 B 和 C 构成。现在你想将 feature 分支合并到 master 分支中。由于 feature 分支的提交历史不是线性的，Git 必须创建一个新的合并提交，该提交包含两个分支的全部更改内容。

总之，"fast-forward" 和 "non-fast-forward" 是 Git 中与分支合并相关的概念，用于描述将一个分支合并到另一个分支时所采用的策略。

一个项目的远端push

想象一个场景，我们在远端创建了一个仓库，并初始化了一个commit提交。这时我们本地也创建了几个提交，并与远端建立remote关系，此时我们进行push，大概率会出现下面的错误。

这个错误表示有些提交我们本地是没有的，我们需要先对远端的仓库进行pull操作，将远端的commit拉到本地。

不是fast-forward

此时，需要通过merge生成一个新的节点。

当我们在本地master合并远程的master时，会出现下面的情况

表示本地的分支和远程的分之是没有相关的历史提交的

那应该怎么办呢，通过查看merge帮助，可以使用以下命令：

可见，生成了一个新的commit

此时本地分支和远端的分支就是fast-forward了。

不同的人修改不同的文件

ahead 1 比远端多一个commit

behind 1 远端比本地多一个

此时可能不是fast-forward，我们需要使用merge进行操作

本地merge远端

不同的人修改了相同文件的不同区域

也会发生非fast-forward，也需要进行merge操作。

不同人修改相同的区域

需要进行merge，会产生冲突，到指定文件中去解决冲突。

同时变更了文件名和文件内容

merge时，会自动更改文件名字，比较智能

把同一文件名进行修改

会自动出现两个文件，由程序员来进行处理