git merge 和 rebase 区别

git pull  超级不推荐使用git pull 有坑,谨慎使用,pull底层是merge

git pull 是 git fetch + git merge FETCH_HEAD 的缩写。所以,默认情况下,git pull就是先fetch,然后执行merge 操作,如果加 —rebase 参数,就是使用git rebase 代替git merge。

merge 和 rebase

merge 是合并的意思,rebase是复位基底的意思。

现在我们有这样的两个分支,test和master,提交如下:


1

2

3


D---E test

/

A---B---C---F master

在master执行 git merge test ,然后会得到如下结果:


1

2

3


D--------E

/ \

A---B---C---F----G test, master

在master执行 git rebase test ,然后得到如下结果:


1

A---B---D---E---C ‘---F‘ test, master

可以看到,merge操作会生成一个新的节点,之前的提交分开显示。而rebase操作不会生成新的节点,是将两个分支融合成一个线性的提交。

其他内容放这里

通过上面可以看到,想要更好的提交树,使用rebase操作会更好一点。这样可以线性的看到每一次提交,并且没有增加提交节点。

在我们操作过程中。merge 操作遇到冲突的时候,当前merge不能继续进行下去。手动修改冲突内容后,add 修改,commit 就可以了。

而rebase 操作的话,会中断rebase,同时会提示去解决冲突。解决冲突后,将修改add后执行git rebase —continue继续操作,或者git rebase —skip忽略冲突。

时间: 2024-10-13 21:24:33

git merge 和 rebase 区别的相关文章

Git merge 和 rebase的区别

原文地址:http://blog.csdn.net/hudashi/article/details/7664631 git rebase用于把一个分支的修改合并到当前分支. 假设你现在基于远程分支"origin",创建一个叫"mywork"的分支. $ git checkout -b mywork origin 假设远程分支"origin"已经有了2个提交,如图 现在我们在这个分支做一些修改,然后生成两个提交(commit). $ vi file

闲谈 git merge 与 git rebase 的区别

前言 相信大部分使用 Git 的朋友都会遇见相同的疑问,并且也从网上搜索了不少资料.那么,为什么我还要写这篇文章呢?因为我想尝试从自己的角度解释这个问题,如果能给到大家灵光一闪的感悟,便善莫大焉啦.估计点进来的朋友也对 merge 和 rebase 有了一定了解,所以我也就不浪费篇幅再去详细介绍 merge 和 rebase,让我们直入主题吧. merge 与 rebase 的区别 merge 现在假设我们有一个主分支 master 及一个开发分支 deve,仓库历史就像这样:现在如果在 mas

git各种命令 & git merge和git rebase的区别

git merge 和 rebase的区别: http://blog.csdn.net/jollyjumper/article/details/24743751 对于两个分支而言,rebase和merge没有区别,但是rebase更干净,因为log hisitory是线性的,但commit不一定按日期先后排,而是local commit总在后面,merge之后history变得比较复杂,但是commit按日期排序,stackoverflow上有个图示很好: http://stackoverflo

git merge时merge/squash merge/rebase merge的区别

1. merge $ git checkout master $ git merge dev 这是最基本的 merge,会把分支的提交历史原封不动地拷贝过来,如果 master 此后已经有了新的提交,那么本次 merge 时还会额外自动创建一条 commit 信息用于记录本次 merge 操作. 2. squash merge $ git checkout master $ git merge --squash dev 字面意思,相比?merge?来说会减少分支合并的记录,会被压缩为一条 com

git merge rebase的区别及应用场景

前两天和同事交流发现他在日常开发中跟上游保持同步每次都是用git pull操作,而我一直习惯git fetch然后rebase,发现这两种操作后的log是有些区别的.他每次pull操作之后都会自动生成一个merge记录,而使用fetch+rebase就没有. 查了下发现其实就是git pull命令两种参数的区别: git pull --merge  默认参数,相当于:git fetch + git merge git pull --rebase 手动指定,相当于:git fetch + git

git merge和git rebase的区别(转)

Description git rebase 和 git merge 一样都是用于从一个分支获取并且合并到当前分支,但是他们采取不同的工作方式,以下面的一个工作场景说明其区别 场景:  如图所示:你在一个feature分支进行新特性的开发,与此同时,master 分支的也有新的提交. 为了将master 上新的提交合并到你的feature分支上,你有两种选择:merging or rebasing merge 执行以下命令: git checkout feature git merge mast

Git分支merge和rebase的区别

Git merge是用来合并两个分支的. git merge b # 将b分支合并到当前分支 同样 git rebase b,也是把 b分支合并到当前分支 原理 如下: 假设你现在基于远程分支"origin",创建一个叫"mywork"的分支. $ git checkout -b mywork origin 假设远程分支"origin"已经有了2个提交,如图 现在我们在这个分支做一些修改,然后生成两个提交(commit). $ vi file.t

git merge 与 git rebase的区别

前言 其实这个问题困扰我有一段时间,相信也有人和我一样有这个困扰,网上已有很多这种解释了,但是要么就是无图,要么就是解释的很乱,没太看懂,经过自己对git的使用,加上向同事请教,算是理解了这个问题,所以写下来分享一下,我尽量详细说明merge与rebase的区别 假设我们有如下图一所示仓库,该仓库有master和develop两个分支,且develop是在(3.added merge.txt file)commit处从master拉出来的分支.图一 merge 假设现在HEAD在(6.added

git rebase 和 git merge的区别

原文链接:http://zires.info/tag/git-merge/ git merge是用来合并两个分支的. # 将b分支合并到当前分支git merge b git cherry-pick可以选择某一个分支中的一个或几个commit(s)来进行操作.例如,假设我们有个稳定版本的分支,叫v2.0,另外还有个开发版本的分支v3.0,我们不能直接把两个分支合并,这样会导致稳定版本混乱,但是又想增加一个v3.0中的功能到v2.0中,这里就可以使用cherry-pick了. # 先在v3.0中查