有意与无意之间

fast-forward

未添加任何参数使用git merge合并分支时即为fast-forward模式，这种模式不是在被合并分支上显示被合并的分支，只保留单条分支记录。在合并时间，GIT直接将HEAD指针指向合并分支的头，完成合并，这是一种”快进"方式的合并。 在这种情况下，删除分支，则分支丢失，只在被合并分支上看到commit提交信息，但并不知道来源。

合并前

featue       D->E
            /
master A->B->C

合并后

master A->B->C->D->E

--no-off

由于fast-forward方式是一种快进合并，无法体现合并来源，所以--no-off方式就更为有用，--no-off在合并后会保留分支信息，即使被合并的分支删除，也不会丢失。

合并前

featue       D->E
            /
master A->B->C

合并后

featue       D->E
            /   \
master A->B->C--->F

--squash

--squash可以将被合并分支上的多余的commit进行合并，它不会移动head，他会忽略之前所有的commit后进行所有，由于之前commit全部被忽略，所以你还需要最后一次commit做一个总结

featue       D->E
            /  
master A->B->C--->F

featue        F
            /  \
master A->B->C-->G

三种模式的适用场景

fast-forward更适用于多用于协作开发feature或hotfix，由上级领导合并各自开发的feature和hotfix内容，因为这些作为一个整体存在即可，且在开发过程中看见状态

--no-off适合将devlop分支合并到relase分支， 发布分支最终需要合并到master分支上，所以需要保留开发历史，并不适合hotfix向其他分支合并

--squash 适合hotfix向其他分支合并，因为热修复通常都只修复一个单一的整体的BUG。但并不一定适合feature向其他分支合并，因为如果同一个feature， 如果有隔离的 协作的功能，且在同一个迭代周期内完成的， 就需要保留这些信息和状态。