Git merge fast-forward/–no–off/–squah的区别

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, 如果有隔离的 协作的功能,且在同一个迭代周期内完成的, 就需要保留这些信息和状态。

发表评论

邮箱地址不会被公开。 必填项已用*标注