一、non-fast-forward 的意义和原因
当我们使用 Git 管理项目时，我们经常需要从一个分支合并到另一个分支。在合并时，Git 有两种方式：fast-forward 和 non-fast-forward。
fast-forward 的合并方式是将当前分支直接指向目标分支，这种方式实现起来简单快捷，也没有任何副作用。
然而，如果当前分支在上一次提交之后还在进行了一些提交，那么这个合并操作就不能使用 fast-forward 方式了。这时 Git 会采用非 fast-forward 方式实现合并。这种方式会在当前分支的基础上新建一个提交记录，这个提交记录会将目标分支并入当前分支。由于这种方式会新建一个提交记录，所以叫做 non-fast-forward。
二、如何避免 non-fast-forward 的情况
避免 non-fast-forward 的方法有很多，我们可以从代码管理的方面和工作流的方面入手。
1. 使用 rebase
一种避免 non-fast-forward 的方法是使用 git rebase 命令。
git checkout feature
git rebase master
这段代码的含义是先切换到 feature 分支，然后将 master 分支里的提交逐个应用到 feature 分支上，也就是将 feature 分支上的提交“移植”到 master 分支上，最后切换回 master 分支，将 feature 分支合并入 master 分支。这时，由于 feature 分支上的所有提交都已经“移植”到了 master 分支上，因此 Git 可以选择使用 fast-forward 方式完成合并。
2. 合并前先拉取代码
为了避免 non-fast-forward，我们应该合并前先拉取代码，确保当前分支在合并前是最新的。
git pull origin master
git merge feature
这段代码的含义是先从远程仓库拉取 master 分支的最新代码，然后将 feature 分支合并入 master 分支。这时如果出现 non-fast-forward，我们可以通过 rebase 或者强制覆盖的方式解决掉。
3. 修改工作流规范
我们还可以通过修改团队的工作流规范来避免 non-fast-forward。比如，我们可以规定所有的提交必须合并成一个单一的提交，并使用 rebase 方式实现。
三、non-fast-forward 的注意事项
无论我们采用何种方法避免 non-fast-forward，我们都需要注意一些事项。
1. 避免重复提交
一旦提交了重复的代码，就会出现 non-fast-forward 的情况。
2. 慎用强制覆盖
在出现 non-fast-forward 的情况下，我们可以使用强制覆盖的方式实现合并。但是这种方式会覆盖掉目标分支上的提交记录，因此要慎用。
3. 注意版本兼容性
在使用 rebase 的同时，我们需要注意版本兼容性，因为 rebase 可能会导致提交历史的不兼容。如果合并后的代码有版本兼容性问题，我们需要及时调整代码，避免影响工作进展。
