到目前为止，我们已经使用过两次merge操作，一次是直接合并没有发生冲突，一次合并发生冲突解决冲突后在重新提交。 对于这两次merge操作其实分别对应了Git提供给我们两个merge模式。
通常合并分支时，如果可能，Git 会采用 Fast forward 模式。
可以清楚看到使用Fast - forward 快进模式 ，在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：
那么这就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其他分支合并得到：
Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成⼀个新的 commit ，这样，从分支历史上就可以看出分⽀信息。
git merge --no-ff -m "xxxx" [分支]
可以看到，不使用 Fast forward 模式，merge后就像下面这样，所以在合并分支时，加上 --no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾
经做过合并，而 fast forward 合并就看不出来曾经做过合并。
合并我们建议不要使用Fast-forward，而使用no-ff。