3图带你理解rebase和merge

最新推荐文章于 2024-08-07 16:04:55 发布
最新推荐文章于 2024-08-07 16:04:55 发布
阅读量5.5k 收藏 16
点赞数 3
分类专栏： linux git 文章标签： linux git
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq8427003/article/details/64921010
版权
linux 同时被 2 个专栏收录
15 篇文章 0 订阅
订阅专栏
git
3 篇文章 0 订阅
订阅专栏

分享请标明来自: https://www.css3.io/rebase-vs-merge.html



背景

如果用一句话来描述 git rebase 和 git merge的最大区别，那就是： 两种合并所产生的log不一样。

小结

从上图中看，rebase与merge的区别有些体现了，即它们产生的log tree不一样。我们放大这种效果再看

merge vs rebase

总结

我们的分支模型最简单实用的，无外乎分支开发主干合并。每当我们需要开发一个新特性时，就会创建一个特性分支。

  1. 当使用merge时，最后合产生的log随着特性分支的增多，log tree显得非常凌乱（其实也不凌乱，只是对比rebase模式而言）。

  2. 当使用rebase时，最后产生的log tree会成一条线，而依然能够清晰看出特性分支，图中黄色圈起来的地方。这是与merge的最大区别。

  3. 当然还有其它的不同

    a. 比如merge合并时会产生一个多余的节点（有些人认为这个节点没有任何意义，其实这代表了合并，怎么会没有意义呢？） 。

    b. 再比如rebase 在合并冲突时，可能没有merge好用（rebase会根据时间来diff，比如master 改了文件1某个地方，commit了，dev 改了文件1同一处，commit了，dev 又改了文件1同一处， commit了。此时期望的是dev最后1次commit的与master commit的 diff就行了，但是rebase还得diff多次。

  4. rebase 最好不用于公共分支等我们就不讨论了。rebase与merge的具体实战操作并不难，就不作演示了。

参考

https://www.youtube.com/watch?v=a_msiOrYLgM

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

https://www.youtube.com/watch?v=SxzjZtJwOgo

https://blog.yorkxin.org/2011/07/29/git-rebase

http://blog.isming.me/2014/09/26/git-rebase-merge/

https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history#squash-commits-together

8427003
关注
专栏目录
面试官：说说 git 发生冲突的场景？如何解决？​
weixin_44475093的博客
08-18 1957
一、是什么一般情况下，出现冲突的场景有如下：多个分支代码合并到一个分支时多个分支向同一个远端分支推送具体情况就是，多个分支修改了同一个文件（任何地方）或者多个分支修改了同一个文件的名称如果...
[git]merge和rebase的区别
weixin_33834628的博客
08-06 3403
前言 我从用git就一直用rebase，但是新的公司需要用merge命令，我不是很明白，所以查了一些资料，总结了下面的内容，如果有什么不妥的地方，还望指正，我一定虚心学习。 merge和rebase 标题上的两个命令：merge和rebase都是用来合并分支的。 这里不解释rebase命令，以及两个命令的原理，详细解释参考这里。 下面的内容主要说的是两者在实际操作中的区别。 什么是分支 分支就是便...
什么是rebase
最新发布
m0_57236802的博客
08-07 748
rebase是一个强大的工具，可以帮助你保持提交历史的整洁和线性。通过将一系列提交移到另一个基准之上，它可以简化历史记录，使其更易于阅读和理解。在使用rebase时，需要注意避免在公共分支上重写历史，以防止对团队协作造成不良影响。
git rebase与git merge图文详解（一文看懂区别）
weixin_45565886的博客
10-12 1万+
git-rebase与git merge图文详解
Git命令解析 - merge、rebase(差异和选择)
huang007guo的专栏
01-15 1866
merge 和 rebase 的差异: 1.merge 保持了所有分支的原始修改记录并且会生成一条合并的记录,rebase把合并的分支的提交记录摘取出来重新提交生成新的提交也可整合后生成新的提交 2.merge后可以使用git blame追溯代码的作者,rebase后使用git blame出来的作者将都是rebase的人 3.rebase整合可以忽略一些重复的修改,或者忽略掉修改了又该回来的...
git rebase 与 merge 的那些事儿~（详细图解，通俗易懂）
张兴华的博客
08-01 2467
什么是 rebase? git rebase 你其实可以把它理解成是“重新设置基线”，将你的当前分支重新设置开始点。这个时候才能知道你当前分支于你需要比较的分支之间的差异。 原理很简单：rebase 需要基于一个分支来设置你当前的分支的基线，这基线就是当前分支的开始时间轴向后移动到最新的跟踪分支的最后面，这样你的当前分支就是最新的跟踪分支。这里的操作是基于文件事务处理的，所以你不用怕中间失败会影...
git之merge和rebase
wang0907的博客
05-19 8060
写在前面 不管是merge，还是rebase都是将一个分支的修改合并到另一个分支，但是方式方法有所不同，下面我们具体来看下每种情况。 1：merge merge就是合并代码，这种方式合并代码后，合并的结果会生成一个新的commit（效果同手动修改后的提交），而merge又有两种方式分别是fast-forward和，非fast-forward，分别来看下这两种方式。 1.1：fast-forward 当合并代码的时候，如果是没有冲突(更准确的表述应该是文件不需要合并时)，git就会默认采用这种方式，接下来看下
Merge还是Rebase？这次终于懂了
小韩的博客
01-06 4057
《Git分支管理：Merge还是Rebase？》 介绍、优缺点、使用场景、示例结果
Git的merge和rebase你真的了解吗？
01-23
在个人开发中，`rebase`更受欢迎，因为它可以保持提交历史的线性，便于阅读和理解。 在多版本并行开发的场景中，`merge`和`rebase`的使用策略会有所不同。例如，在团队较小的情况下，可以共用一个开发分支，通过`...
git rebase 和 merge 的区别
sisterAn的博客
03-31 716
git rebase 与 git merge 解决了相同的问题。都是将一个分支的提交合并到另一分支上，那它们有哪些不同喃？ git merge master 分支合入到 feature 分支 git checkout feature git merge master // 或者 git merge master feature git merge 的优势是它保留了分支的结构与历史提交目录，但同时这也导致了提交历史会被大量的 merge 污染 git rebase rebase命令是一个经常听到，但..
Git：pull --rebase 和 merge --no-ff
dielucui7698的博客
12-12 639
首先是吐嘈 如果你正在 code review，看到上图（下文将称之为：提交线图）之后，特别是像我这样有某种洁癖的人，是否感觉特别难受？如果是的话，请看下文吧 :) 为什么 Git 作为分布式版本控制系统，所有修改操作都是基于本地的，在团队协作过程中，假设你和你的同伴在本地中分别有各自的新提交，而你的同伴先于你 push 了代码到远程分支上，所以你必须先执行 git pull ...
详解git merge 与 git rebase的区别
10-15
当执行 `git merge` 时，Git 会找到两个分支的最近共同祖先（在本例中是 `(3.added merge.txt file)`），然后对比这个共同祖先和两个分支的最新提交（`(6.added hello.txt file)` 和 `(5.added test.txt file)`）。...
Merge和Rebase的区别
FirstMrRight的博客
08-08 1060
变基的结果是源分支上的提交被重新应用到目标分支上，创建了新的提交。变基是将一个分支的提交移动到另一个分支的末尾，使提交历史看起来像是在一个分支上进行的连续修改。Merge 保留了分支的独立提交历史，而 Rebase 则将分支的提交移动到其他分支的最新提交之后，使提交历史保持线性。需要注意的是，当使用 Rebase 时，由于修改提交历史的特性，可能需要解决冲突，并且可能会导致其他开发者基于原始提交历史构建的分支出现问题。合并的结果是一个新的提交，它将源分支的修改合并到目标分支中。
【Git系列】merge和rebase的区别
檀越的博客
07-29 1万+
merge和rebase都是 Git 中用于合并分支的命令，但它们的合并方式和结果略有不同。merge命令的作用是将两个分支合并成一个新的提交，新的提交有两个父提交。这种合并方式会创建一个新的提交，它包含了被合并的分支的所有更改。这样就可以将两个不同的分支中的代码变更合并到一起。rebase命令的作用是将当前分支的提交移动到另一个分支的最新提交之后，相当于重新应用一遍当前分支的所有提交。这种合并方式会使得提交历史变得更加线性，因为提交会被“重放”在新的基础分支上。在执行rebase。
rebase 和 merge 的区别么？
06-30 1万+
大概来说，git merge和git rebase都是用来做代码合并的，两者从最终效果来看没有任何区别，都是将不同分支的代码融合在一起。 但是在遇到冲突和具体使用场景上有一些不同。 一、rebase rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。 举例:如果你从 master 拉了个feature分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master ..
git rebase 和merge 区分
许佳佳的博客
03-09 1244
本文参考 https://backlog.com/git-tutorial/cn/stepup/stepup1_4.html rebase和merge区分 相同点 两者都可以合并代码。 不同点 比如现在在某个子分支执行git rebase(merge) master操作。 merge:将在子分支的所有提交记录成一次commit，保留在记录中。（下图的E即为该记录） rebase:不会保留com...
深入理解Git：rebase与merge
wujiayu31415的博客
06-27 459
它会取出一个公共的祖先节点，然后尝试将两个分支从该节点开始发生的所有变化都合并到一起，最终生成一个新的节点（合并提交）。这个新节点会包含两个分支的所有修改。它会先将当前分支上的所有提交临时保存，然后将当前分支更新到目标分支的最新状态，接着将之前保存的提交逐个应用到目标分支的最新状态上，形成一个新的线性提交历史。在实际开发中，我们应该根据项目的需求、团队的规模和成员的Git使用经验来选择合适的操作。然而，很多开发者在使用时容易混淆，今天我们就来详细解析一下两者的区别、优缺点，并通过实战代码来演示它们的用法。
git fetch、git rebase和merge区别
热门推荐
muzidigbig的博客
01-16 2万+
一、概述 merge和rebase 标题上的两个命令：merge和rebase都是用来合并分支的。 这里不解释rebase命令，以及两个命令的原理，详细解释参考这里。 下面的内容主要说的是两者在实际操作中的区别。 1.1 什么是分支 分支就是便于多人在同一项目中的协作开发。比方说：每个人开发不同的功能，在各自的分支开发过程中互不影响，完成后都提交到develop分支。极大的提高了开发的效率。 1.2 合并分支 每个人创建一个分支进行开发，当开发完成，需要合并到develop分支的时候，就需要
git merge和rebase的区别
icy_xm的专栏
12-22 841
一直以来都以为rebase是合并冲突的一种手段，和merge一样的，有哪个都行。今天才决定把他们搞懂了。我是有多么的懒。。 git merge 会生成一个新得合并节点，而rebase不会      D---E test / A---B---C---F master 使用merge合并后 D--------E / \ A---
sourcetree rebase 和 merge的区别
07-15
### 回答1： Sourcetree是一个用于管理Git仓库的可视化工具。在Sourcetree中，rebase（变基）和merge（合并）是两种不同的操作，它们的区别如下： 1. rebase（变基）操作是将一个分支的修改应用到另一个分支上，使两个分支的提交历史线性地排列在一起。在rebase过程中，会将要变基的分支的修改以补丁的方式应用到目标分支上，然后将目标分支指向最新的补丁提交。这样可以使提交历史更加清晰，更容易理解。 2. merge（合并）操作是将两个分支的修改合并到一起，形成一个新的提交。在merge过程中，会创建一个新的合并提交，包含了两个分支的修改。这样可以快速合并分支，并保留每个分支的独立提交历史。 rebase和merge的使用场景不同： - 当需要在当前分支上应用其他分支的修改时，可以使用rebase操作。例如，当你在本地开发一个feature分支，同时有其他人在远程develop分支上提交了修改，你希望将这些修改应用到自己的分支上，可以使用rebase操作。 - 当需要合并两个独立的分支时，可以使用merge操作。例如，当你在本地开发一个feature分支，完成后需要将该分支合并到主分支上，可以使用merge操作。 总之，rebase和merge是Sourcetree中两种不同的操作，它们分别适用于不同的场景，能够帮助我们更好地管理和协作开发Git仓库。 ### 回答2： Sourcetree是一款Git图形化界面工具，其中有两个常用操作是rebase和merge，它们都是用于处理分支合并的方法。rebase和merge的区别如下： 1. merge（合并）：将一个分支的更改合并到另一个分支上。当我们使用merge时，会在目标分支上创建一个新的合并提交，该提交将包含来自源分支的所有更改。这意味着，会在提交历史中看到一个新的合并节点。 2. rebase（变基）：将一个分支的更改放在另一个分支的基础上。当我们使用rebase时，会将源分支上的提交逐个应用到目标分支的末端。这样，提交历史会更线性，没有创建新的合并节点。 总结来说，rebase和merge的主要区别在于提交历史的处理方式。merge会创建新的合并提交，保持原有的提交历史记录，而rebase会将提交逐个应用到目标分支上，使提交历史更加线性。因此，在选择使用rebase还是merge时需要考虑清楚自己的需求，以及对提交历史记录的要求。 ### 回答3： SourceTree是一款广泛使用的Git图形化界面工具，在进行版本控制时，它提供了两种主要的操作方式，即rebase和merge。 首先，rebase是一种将一系列提交节点（commits）应用到目标分支的操作。它可以将多个提交节点合并成一个更整洁的提交线，使得分支历史看起来更加线性和简洁。在rebase过程中，被合并的提交节点会根据其在当前分支上的位置被依次应用到目标分支上，形成一个新的提交线。Rebase适合于保持代码历史纯净，以及处理功能分支中的冲突。 另一方面，merge是将两个或多个分支的更改集合合并为一个新的提交的操作。当执行merge时，Git会自动创建一个新的提交节点，将两个分支上的更改集合整合在一起。与rebase不同，merge会保留每个分支的历史记录和每个提交节点。Merge适合处理不同分支之间的代码改动，可以方便地在分支之间进行代码合并。 总的来说，rebase和merge有如下区别： 1. Rebase可以使得分支历史更加线性和整洁，而merge则会保留每个提交节点的历史记录。 2. Rebase适合处理功能分支中的冲突，而merge适合处理不同分支之间的代码改动。 3. Rebase会改变分支上的提交顺序和SHA值，而merge不会。 4. Rebase具有潜在的风险，因为它改变了提交历史，可能会导致合并冲突。 在使用SourceTree时，根据项目需求和开发流程，可以选择合适的操作方式，即rebase或merge，来管理和处理代码的合并。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值