rebase和merge的区别

本文对比了git中的rebase和merge两种合并分支的方法,介绍了它们在处理提交记录、冲突解决和分支结构上的差异,以及rebase如何保持分支树线性结构的特点。
摘要由CSDN通过智能技术生成

合并分支用rebase还是merge?

实际开发工作的时候,我们都是在自己的分支开发,然后将自己的分合并到主分支,那合并分支用2种操作,这2种操作有什么区别呢?

git上新建一个项目,默认是有master分支的,将项目克隆到本地,我们的准备工作就完成了

在这里插入图片描述

同学A:

执行git log ,可以看到有一个提交记录,是初始化提交

在这里插入图片描述

新增一个文件a.txt, 再次查看我们的提交记录,有2条提交记录了

在这里插入图片描述

这个时候将本地新commit的记录push到远程仓库,就可以看到我们的2次提交了

同学B:

同学B在已经有提交记录的master分支上,检出分支dev,并将分支推送到远程分支,并进行自己的开发

在这里插入图片描述

查看远程仓库,多了一个dev分支

在这里插入图片描述

此时的git分支类图是这样的

在这里插入图片描述

此时B同学开始进行开发,完成了自己的3次提交工作,使用git log 看一下

在这里插入图片描述

此时git的分支类图是这样子的

在这里插入图片描述

重点

现在有这样一个现实的请况,就是B同学准备进行第4次提交的时候,同学A在master主分支上进行了一次提交,master的提交已经向前走了

此时的git分支类图是这样的

在这里插入图片描述

此时我们知道B同学开发的dev分支是基于C2提交点切出来的,而这个时候master分支已经被更新了

如果B同学开发完毕,需要将其所作的功能合并到master分支 ,他可以有两种选择:

直接git merge,那么这个时候会这么做

  • 找到master和dev的共同祖先,即C2
  • 将dev的最新提交C5和master的最新提交即C6合并成一个新的提交C7,有冲突的话,解决冲突
  • 将C2之后的dev和master所有提交点,按照提交时间合并到master

在这里插入图片描述

直接git rebase

切换分支到需要rebase的分支,这里是dev分支

执行git rebase master,有冲突就解决冲突,解决后直接git add . 再git rebase --continue即可

发现采用rebase的方式进行分支合并,整个master分支并没有多出一个新的commit,原来dev分支上的那几次(C3,C4,C5)commit记录在rebase之后其hash值发生了变化,不在是当初在dev分支上提交的时候的hash值了,但是提交的内容被全部复制保留了,并且整个master分支的commit记录呈线性记录

此时git的分支类图

在这里插入图片描述

总结

  • git merge 会让2个分支的提交按照提交时间进行排序,并且会把最新的2个commit合并成一个commit。最后的分支树呈现非线性的结构

  • git reabse 将dev的当前提交复制到master的最新提交之后,会形成一个线性的分支树

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值