git merge(3个模式) 与 git rebase 图文详解区别

目录

  • [1 git merge](#1 git merge)
    • [1.1 模式一:fast-forward(--ff)](#1.1 模式一:fast-forward(–ff))
    • [1.2 模式二:non-Fast-forward(--no-ff)](#1.2 模式二:non-Fast-forward(–no-ff))
    • [1.3 模式三:fast-forward only(--ff-only)](#1.3 模式三:fast-forward only(–ff-only))
  • [2 git rebase](#2 git rebase)
  • [3 区别](#3 区别)

1 git merge

git merge有好几种不同的模式

默认情况下你直接使用 git merge 命令,git 来判断使用哪种 merge 模式

1.1 模式一:fast-forward(--ff)

master 与 feature存在公共祖先的情况

开发者小王接到需求任务,从 master 分支中创建功能分支,git 指令如下:

bash 复制代码
git checkout -b feature556
Switched to a new branch 'feature556'

小王在 feature556 分支上完成的功能开发工作,然后产生1次 commit

功能完成后自然要上线,我们把代码合并,完成上线动作

bash 复制代码
git checkout master
git merge feautre556

Fast-forward 是指 Master 合并 Feature 时候发现 Master 当前节点一直和 Feature 的根节点相同,没有发生改变,那么 Master 快速移动头指针到 Feature 的位置,所以 Fast-forward 并不会发生真正的合并,只是通过移动指针造成合并的假象,这也体现 git 设计的巧妙之处。合并后的分支指针如下:

1.2 模式二:non-Fast-forward(--no-ff)

master与feature不存在公共祖先

刚说了会产生 Fast-forward 的情况,现在再说说什么情况会产生 non-Fast-forward,通常,当合并的分支跟 master 不存在共同祖先节点的时候,这时候在 merge 的时候 git 默认无法使用 Fast-forward 模式,

可以看到 master 分支已经比 feature556 快了1个版本,master 已经没办法通过移动头指针来完成 Fast-forward,所以在 master 合并 feature001 的时候就不得不做出真正的合并,真正的合并会让 git 多做很多工作,具体合并的动作如下:

  • 找出 master 和 feature001 的公共祖先,节点 c1,c2, c3 三个节点的版本 (如果有冲突需要处理)
  • 创建新的节点 c4,并且将三个版本的差异合并到 c4,并且创建 commit
  • 将 master 和 HEAD 指针移动到 c7

补充⭐:大家在 git log 看到很多类似:Merge branch 'feature556' into master 的 commit 就是 non-Fast-forward 产生的。

执行完以上动作,最终分支流程图如下:

1.3 模式三:fast-forward only(--ff-only)

...

2 git rebase

我们在自己的分支feature上开发了一段时间了(此时feature的基底是a),准备从主干master上拉一下最新改动

此时我们切换到feature分支上,执行rebase命令,想要把master分支合并到feature分支

bash 复制代码
git checkout feature
git rebase master

下图为变基后的提交节点图

rebase,变基,可以直接理解为改变基底。

feature分支是基于master分支的B拉出来的分支,feature的基底是a。而master在a之后有新的提交,到了c,就相当于此时要用master上新的提交来作为feature分支的新基底。

实际操作为把feature的提交先暂存下来,然后删掉原来这些提交,再找到master的最新提交位置,把存下来的提交再接上去(接上去是逐个和新基底处理冲突的过程),如此feature分支的基底就相当于变成了c而不是原来的a了。

(注意,如果master上在a以后没有新提交,那么就还是用原来的a作为基,rebase操作相当于无效,此时和git merge就基本没区别了,差异只在于git merge会多一条记录Merge操作的提交记录)

3 区别

  • rebase:变基,会有一个干净的分支,但是对于记录来源不够清晰
  • merge:合并,git分支看起来比较混乱,但是清楚各个记录的来源与时间节点

建议都用 merge

相关推荐
&Sinnt&14 小时前
Git 版本控制完全指南:从入门到精通
git·后端
Tiny21417 小时前
多人协同开发时Git使用命令
git
WebGirl18 小时前
代码Revert后再次Merge会丢失的问题
git
小皮侠1 天前
nginx的使用
java·运维·服务器·前端·git·nginx·github
HalukiSan1 天前
如何提交PR
git·gitlab·github
爱莉希雅&&&1 天前
shell编程之awk命令详解
linux·服务器·git
baiyu331 天前
成为git砖家(12): 看懂git合并分支时冲突提示符
git
wu_aceo2 天前
将本地项目提交到Gitee
git·gitee·提交·本地提交·上传git
随便取个六字2 天前
GIT操作 学习
git·学习
星源~2 天前
tree 命令集成到 Git Bash:可视化目录结构的指南
git·单片机·物联网·嵌入式·项目开发