当前位置: 首页> 健康> 科研 > 【Git分支管理】分支2种合并模式

【Git分支管理】分支2种合并模式

时间:2025/7/11 0:27:51来源:https://blog.csdn.net/m0_74841364/article/details/140436926 浏览次数:0次

目录

0.回顾

1.ff模式

2.no-ff模式

3.ff模式转no-ff模式


  • 先提交再合并再提交 

0.回顾

前面介绍了两种情况总结如下: 

  1. master没有修改提交,在dev中修改提交,master和dev合并顺利
  2. master修改提交的同时dev也修改提交了,产生合并冲突☞手动解决☞并再次提交

这两次merge操作分别对应git给我们提供了两次的merge模式。ff模式和no-ff模式。

git log --graph --abbrev-commit 

1.ff模式

Faster forward:git提供的第一种模式(faster forward模式)

  • 将master分支中的内容commit id修改为dev2分支中最新一次提交的commit id
  • 在这种 Fast forward 模式下,删除分⽀后,查看分⽀历史时,会丢掉分⽀信息,看不出来最新提交到底是 merge 进来的还是正常提交的。
  • 此次merge用到是faster-forward模式:看不出是master提交的,还是dev2提交的合并的

2.no-ff模式

no-faster-forward模式:git提供的第二种模式(非faster forward模式)

  • 合并冲突之后,手动解决之后,又进行一次提交。
  • 可以明显看出是合并之后提交的。
  • 这样的好处是,从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀,但依旧能看到 master 其实是由其他分⽀合并得到。

3.ff模式转no-ff模式

git merge --no-ff -m "merge再次提交描述提交的详细信息"  dev2(合并的分支名称)

git merge --no-ff -m "merge with no-ff" dev2

本质是为了回溯历史的时候:到底是直接master提交,还在别的分支上dev2提交了再合并的

关键字:【Git分支管理】分支2种合并模式

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

责任编辑: