精华内容
参与话题
问答
  • git rebase简介(基本篇)

    万次阅读 多人点赞 2012-06-14 22:09:19
    git rebase用于把一个分支的修改合并到当前分支。 假设你现在基于远程分支"origin",创建一个叫"mywork"的分支。 $ git checkout -b mywork origin 假设远程分支"origin"已经有了2个提交,如图 现在我们在这...

    原文:

    http://gitbook.liuhui998.com/4_2.html

    一、基本

    git rebase用于把一个分支的修改合并到当前分支。

    假设你现在基于远程分支"origin",创建一个叫"mywork"的分支。

    $ git checkout -b mywork origin

    假设远程分支"origin"已经有了2个提交,如图

     

    现在我们在这个分支做一些修改,然后生成两个提交(commit).

    $ vi file.txt

    $ git commit

    $ vi otherfile.txt

    $ git commit

    ...

    但是与此同时,有些人也在"origin"分支上做了一些修改并且做了提交了. 这就意味着"origin"和"mywork"这两个分支各自"前进"了,它们之间"分叉"了。

     

     

    在这里,你可以用"pull"命令把"origin"分支上的修改拉下来并且和你的修改合并; 结果看起来就像一个新的"合并的提交"(merge commit):

     

    但是,如果你想让"mywork"分支历史看起来像没有经过任何合并一样,你也许可以用 git rebase:

    $ git checkout mywork

    $ git rebase origin

    这些命令会把你的"mywork"分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支,最后把保存的这些补丁应用到"mywork"分支上。

     

    当'mywork'分支更新之后,它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. (请查看 git gc)

     

    二、解决冲突

    rebase的过程中,也许会出现冲突(conflict). 在这种情况,Git会停止rebase并会让你去解决 冲突;在解决完冲突后,用"git-add"命令去更新这些内容的索引(index), 然后,你无需执行 git-commit,只要执行:

    git rebase --continue

    这样git会继续应用(apply)余下的补丁。

    在任何时候,你可以用--abort参数来终止rebase的行动,并且"mywork" 分支会回到rebase开始前的状态。

    git rebase --abort

    三、git rebasegit merge的区别

    现在我们可以看一下用合并(merge)和用rebase所产生的历史的区别:

    当我们使用Git log来参看commit时,其commit的顺序也有所不同。

    假设C3提交于9:00AM,C5提交于10:00AM,C4提交于11:00AM,C6提交于12:00AM,

    对于使用git merge来合并所看到的commit的顺序(从新到旧)是:C7 ,C6,C4,C5,C3,C2,C1

    对于使用git rebase来合并所看到的commit的顺序(从新到旧)是:C7 ,C6‘,C5',C4,C3,C2,C1

     因为C6'提交只是C6提交的克隆,C5'提交只是C5提交的克隆,

    从用户的角度看使用git rebase来合并后所看到的commit的顺序(从新到旧)是:C7 ,C6,C5,C4,C3,C2,C1

     另外,我们在使用git pull命令的时候,可以使用--rebase参数,即git pull --rebase,这里表示把你的本地当前分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把本地当前分支更新 为最新的"origin"分支,最后把保存的这些补丁应用到本地当前分支上。关于git pull的更多内容请参考《git pull简介

    码农学演讲:

    拔草还是种花

    小城故事

    展开全文
  • git merge 与 git rebase的区别

    万次阅读 多人点赞 2019-01-14 13:50:29
     其实这个问题困扰我有一段时间,相信也有人和我一样有这个困扰,网上已有很多这种解释了,但是要么就是无图,要么就是解释的很乱,没太看懂,经过自己对git的使用,加上向同事请教,算是理解了这个问题,所以写下...

    前言

          其实这个问题困扰我有一段时间,相信也有人和我一样有这个困扰,网上已有很多这种解释了,但是要么就是无图,要么就是解释的很乱,没太看懂,经过自己对git的使用,加上向同事请教,算是理解了这个问题,所以写下来分享一下,我尽量详细说明

    merge与rebase的区别

            假设我们有如下图一所示仓库,该仓库有master和develop两个分支,且develop是在(3.added merge.txt file)commit处从master拉出来的分支。 
     
    图一

    merge

            假设现在HEAD在(6.added hello.txt file)处,也就是在master分支最近的一次提交处,此时执行git merge develop, 结果如下图所示。 
     
    图二

             工作原理就是:git 会自动根据两个分支的共同祖先即 (3.added merge.txt file)这个 commit 和两个分支的最新提交即 (6.added hello.txt file) 和 (5.added test.txt file) 进行一个三方合并,然后将合并中修改的内容生成一个新的 commit,即图二的(7.Merge branch ‘develop’)。 
            这是merge的效果,简单来说就合并两个分支并生成一个新的提交。

    rebase

          那rebase是这么工作的呢? 
          假设初始状态也是图一所显示的。两个分支一个master,一个develop,此时HEAD在(6.added hello.txt file)处,现在执行git rebase develop,结果如下图三所示。 
     
    图三

            可以看见develop分支分出来分叉不见了,下面来解释一下它的工作原理: 
             在执行git rebase develop之前,HEAD在(6.added hello.txt file)处,当执行rebase操作时,git 会从两个分支的共同祖先 (3.added merge.txt file)开始提取 当前分支(此时是master分支)上的修改,即 (6.added hello.txt file)这个commit,再将 master 分支指向 目标分支的最新提交(此时是develop分支)即(5.added test.txt file) 处,然后将刚刚提取的修改应用到这个最新提交后面。如果提取的修改有多个,那git将依次应用到最新的提交后面,如下两图所示,图四为初始状态,图五为执行rebase后的状态。 
     
    图四

     
    图五

       简单来说,git rebase提取操作有点像git cherry-pick一样,执行rebase后依次将当前的提交cherry-pick到目标分支上,然后将在原始分支上的已提取的commit删除。


    merge OR rebase

    那什么时候用merge,什么时候用rebase呢? 

    再举个例子: 
    初始状态如下图六所示: 
             和之前一样的是,develop分支也是在 (3.added merge.txt file)处从master分支拉取develop分支。不一样的是两个分支各个commit的时间不同,之前develop分支的4和5commit在master分支3之后6之前,现在是develop分支的4提交早于master分支的5提交,develop分支的6提交晚于master的5提交早于master的7提交。 
     
    图六

    在上图情况下,在master分支的7commit处,执行git merge develop,结果如下图七所示: 
     
    图七

    执行git rebase develop,结果如下图八所示: 
     
    图八

    1. 可以看出merge结果能够体现出时间线,但是rebase会打乱时间线。 
    2. 而rebase看起来简洁,但是merge看起来不太简洁。 
    3. 最终结果是都把代码合起来了,所以具体怎么使用这两个命令看项目需要。

           还有一点说明的是,在项目中经常使用git pull来拉取代码,git pull相当于是git fetch + git merge,如果此时运行git pull -r,也就是git pull –rebase,相当于git fetch + git rebase

    最后推荐一些git可视化工具,我用的是gitkraken,这些工具功能基本一样,看个人喜欢好使用


    --------------------- 
    原文:https://blog.csdn.net/liuxiaoheng1992/article/details/79108233 
     

    展开全文
  • 例如现在有两个分支 master 和 ...git checkout feature git merge master # 或者直接指定两个分支: git merge master feature 这样操作后会在 feature 分支上产生一个新的 commit, 这个commit就是包含了 maste

    例如现在有两个分支 master 和 feature, 你在 feature 分支上进行了实验,这时候有个另外的人在 master 分支上进行了新的提交。那么你需要将 master上别人的修改应用到 feature 分支上。

    方法1: merge
    git checkout feature
    git merge master
    
    # 或者直接指定两个分支:
    git merge master feature
    

    这样操作后会在 feature 分支上产生一个新的 commit, 这个commit就是包含了 master 分支的修改。同时历史记录中也会包含这个 commit 的信息。这样会有个好处,也会带来问题。

    好处就是:merge 是 non-destructive 的操作,比较安全。(相对于rebase操作)
    问题就是:如果merge频繁,那么 feature 分支的历史记录中会包含很多个由于 merge 产生的新 commit 信息。这可能不是你希望看到了…)。

    如图:
    在这里插入图片描述

    方法2: rebase

    git checkout feature
    git rebase master // 将 master 上的修改合并到 feature 分支(当前分支)。
    

    rebase 会将 feature 上的历史 commit 全部修改,并且用新的提交覆盖之(即下图中的 Brand New Commit)。
    看起来就是你的 feature 分支从一个开始就是在最新的 master 上开发的( 新的master跑到了你分支的最开始处 )。

    如图(注意比较与上图 merge 的差异):
    在这里插入图片描述
    一个注意点就是不要将 master 分支 rebase 到其他分支上面。这样会导致该 master 分支和其他人的 master 分支的历史记录不一样。然后你还得将你的 master 分支与别人的master分支merge。

    所以,在 rebase 一个分支前想一下别人有没有 watch 这个分支, 因为rebase 会将该分支的历史提交修改。
    see link: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

    展开全文
  • --------------------------------------------------------------------------------------------------------------- 大写的注意:这里解释操作步骤,想了解rebase命令的具体... 要用git fetch先取回, git rebase

    ---------------------------------------------------------------------------------------------------------------

    大写的注意:这里解释操作步骤,想了解rebase命令的具体含义可以看后面内容

    Git rebase 不会取回代码 要用git fetch先取回, git rebase 是合并代码。

    (1)首先用git fetch返回服务器上的代码

    (2)首先用git rebase origin/master 合并

    (3)如果发生冲突了会提示, 然后可以使用git diff查看冲突, 在手工改掉冲突, 在用git add ‘文件名’ 添加修改后文件,最后用git rebase --continue继续没完成的合并

    (4)最后就可以用git push 更新到服务器上去。

    --------------------------------------------------------------------------------------------------------------


    转自: http://blog.chinaunix.net/uid-26952464-id-3352144.html

    Git Community Book 中文版书上,摘录如下:
     
    一、基本
    git rebase用于把一个分支的修改合并到当前分支。
    假设你现在基于远程分支"origin",创建一个叫"mywork"的分支。
    $ git checkout -b mywork origin
    假设远程分支"origin"已经有了2个提交,如图
    现在我们在这个分支做一些修改,然后生成两个提交(commit).
    $ vi file.txt
    $ git commit
    $ vi otherfile.txt
    $ git commit
    ...
    但是与此同时,有些人也在"origin"分支上做了一些修改并且做了提交了. 这就意味着"origin"和"mywork"这两个分支各自"前进"了,它们之间"分叉"了。

    在这里,你可以用"pull"命令把"origin"分支上的修改拉下来并且和你的修改合并; 结果看起来就像一个新的"合并的提交"(merge commit):

     
    但是,如果你想让"mywork"分支历史看起来像没有经过任何合并一样,你也许可以用 git rebase:
    $ git checkout mywork
    $ git rebase origin
    这些命令会把你的"mywork"分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支,最后把保存的这些补丁应用到"mywork"分支上。
     
    当'mywork'分支更新之后,它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. (请查看 git gc)
     
    二、解决冲突
    rebase的过程中,也许会出现冲突(conflict). 在这种情况,Git会停止rebase并会让你去解决 冲突;在解决完冲突后,用"git-add"命令去更新这些内容的索引(index), 然后,你无需执行 git-commit,只要执行:
    git rebase --continue
    这样git会继续应用(apply)余下的补丁。
    在任何时候,你可以用--abort参数来终止rebase的行动,并且"mywork" 分支会回到rebase开始前的状态。
    git rebase --abort
    三、git rebasegit merge的区别
    现在我们可以看一下用合并(merge)和用rebase所产生的历史的区别:
    当我们使用Git log来参看commit时,其commit的顺序也有所不同。
    假设C3提交于9:00AM,C5提交于10:00AM,C4提交于11:00AM,C6提交于12:00AM,
    对于使用git merge来合并所看到的commit的顺序(从新到旧)是:C7 ,C6,C4,C5,C3,C2,C1
    对于使用git rebase来合并所看到的commit的顺序(从新到旧)是:C7 ,C6‘,C5',C4,C3,C2,C1
     因为C6'提交只是C6提交的克隆,C5'提交只是C5提交的克隆,
    从用户的角度看使用git rebase来合并后所看到的commit的顺序(从新到旧)是:C7 ,C6,C5,C4,C3,C2,C1
     
     
    git rebase小计(转)

    git rebase,顾名思义,就是重新定义(re)起点(base)的作用,即重新定义分支的版本库状态。要搞清楚这个东西,要先看看版本库状态切换的两种情况:

    1. 我们知道,在某个分支上,我们可以通过git reset,实现将当前分支切换到本分支以前的任何一个版本状态,即所谓的“回溯”。即实现了本分支的“后悔药”。也即版本控制系统的初衷。
    2. 还有另一种情况,当我们的项目有多个分支的时候。我们除了在本地开发的时候可能会“回溯”外,也常常会将和自己并行开发的别人的分支修改添加到自 己本地来。这种情况下很常见。作为项目管理员,肯定会不断的合并各个子项目的补丁,并将最新版本推送到公共版本库,而作为开发人员之一,提交自己的补丁之 后,往往需要将自己的工作更新到最新的版本库,也就是说把别的分支的工作包含进来。

    举个例子来说吧!假设我们的项目初期只有一个master分支,然后分支上作过两次提交。这个时候系统只有一个master分支,他的分支历史如下:

    master0(初始化后的版本)
    ||
    v
    master1(第一次提交后的版本)
    ||
    v
    master2(第二次提交后的版本)

    这个时候,我们可以通过git reset将master分支(工作目录、工作缓存或者是版本库)切换到master1或者master0版本,这就是前面所说的第一种情况。
    假设我们这里把master分支通过git reset回溯到了master1状态。那么这个时候系统仍然只有一个master分支,分支的历史如下:

    master0(初始化后的版本)
    ||
    v
    master1(第一次提交后的版本)

    然后,我们在这里以master1为起点,创建了另一个分支test。那么对于test分支来说,他的第一个版本test0就和master1是同一个版本,此时项目的分支历史如下:

    master0(初始化后的版本)
    ||
    v
    master1(第一次提交后的版本)===test0(test分支,初始化自master分支master1状态)

    这个时候,我们分别对master分支、test分支作两次提交,此时版本库应该成了这个样子:

    master0(初始化后的版本)
    ||
    v
    master1===test0==>test1===>test2
    ||
    v
    master2===>master3

    1. 这个时候,通过第一种git reset的方式,可以将master分支的当前状态(master3)回溯到master分支的master0、master1、master2状态。 也可已将test分支当前状态(test2)回溯到test分支的test0、test1状态,以及test分支的父分支master的master0、 master1状态。
    2. 那么。如果我要让test分支从test0到test2之间所有的改变都添加到master分支来,使得master分支包含test分支的所有修改。这个时候就要用到git rebase了。

    首先,我们切换到master分支,然后运行下面的命令,即可实现我们的要求:


                         git rebase test

    这个时候,git做了些什么呢?

    1. 先将test分支的代码checkout出来,作为工作目录
    2. 然后将master分支从test分支创建起的所有改变的补丁,依次打上。如果打补丁的过程没问题,rebase就搞定了
    3. 如果打补丁的时候出现了问题,就会提示你处理冲突。处理好了,可以运行git rebase –continue继续直到完成
    4. 如果你不想处理,你还是有两个选择,一个是放弃rebase过程(运行git rebase –abort),另一个是直接用test分支的取代当前分支的(git rebase –skip)。
    展开全文
  • rebase出现冲突后,手动解决冲突,然后执行 “git add 冲突文件”,然后执行“git rebase --continue”,不能执行“git commit” 2)git分支合并冲突解决 https://www.cnblogs.com/shuimuzhushui/p/9022549.html ...
  • 最新更新时间:2020年06月09日15:41:23 《猛戳-查看我的博客地图-总有你意想不到的惊喜》 本文内容:分支管理,分支合并 merge 将功能性分支合并到主分支,此时会在master分支产生一个新的commit记录K ...git pu
  • pick从一个分支合并特定的commits到另一个分支,但是这个方法不能保留原始的提交信息(比如提交时间线等),而如果要保留合并过来的commits的所有提交信息,那么我们就需要使用git rebasegit merge这两个强大的...
  • git在工作中正确的使用方式----git rebase

    万次阅读 多人点赞 2019-01-02 17:45:54
    1.深入理解git rebase
  • 明天就要上班啦,今天姐姐突然问我git-rebase指令是干什么的,怎么用?其实我是不想给他讲的,但是还是没有逃过姐姐的软磨硬泡,那么我们就一起来看一看什么是git-rebase吧!!! 缘起 话说,我和姐姐的缘分是在那...
  • git merge 和 git rebase 小结

    万次阅读 多人点赞 2012-05-10 16:31:04
    git merge是用来合并两...同样 git rebase b,也是把 b分支合并到当前分支 ----------------------------------- 他们的 原理 如下: 假设你现在基于远程分支"origin",创建一个叫"mywork"的分支。 $ git
  • Git rebase详细解析

    万次阅读 2018-02-08 11:20:37
    git rebasegit merge 做的事其实是一样的。它们都被设计来将一个分支的更改并入另一个分支,只不过方式有些不同。 merge 命令示例 git checkout feature git merge master 这样feature 分支中新的合并提交...
  • [Git] Git整理(四) git rebase 的使用

    万次阅读 2018-06-28 23:18:58
    在之前总结分支相关内容时说道,合并两个分支的提交可以使用git merge,然而除了这种方式之外,还有一种方式就是使用git rebase,这两种方式的最终结果都相同,但是合并历史却不同;git merge是将两个分支做一个三方...
  • git rebase解决提交冲突

    万次阅读 2016-11-29 09:55:45
    1、更改完代码后,git push 发生错误 注: 此时,使用git pull: 更新代码,git 会自动merge不同的更新, a. 如果git 自动merge成功,再进行 git push操作就会成功。 b. 如果git 自动merge失败,使用git ...
  • git rebase

    2020-10-30 18:50:44
    git rebase用于把一个分支的修改合并到当前分支。 假设你现在基于远程分支"origin",创建一个叫"mywork"的分支。 $ git checkout -b mywork origin 假设远程分支"origin"已经有了2个提交,如图 现在我们在这...
  • git rebase 理解

    万次阅读 2018-07-04 15:12:38
    原文:http://gitbook.liuhui998.com/4_2.html一、基本git rebase用于把一个分支的修改合并到当前分支。假设你现在基于远程分支"origin",创建一个叫"mywork"的分支。$ git checkout -b mywork ...
  • git stashgit pull —rebasegit stash pop手动解决冲突git add -ugit rebase —continue如果此时提示No rebase in progress?则表示已经没有冲突了;否则上面两步要重复多次git commit -m “xxx”git push origin ...
  • git rebase -i 详解 变基时有六个命令可用: pick 更改提交顺序、删除提交 record 修改提交消息(提交内容不变) edit修改提交 squash合并提交 fixup合并提交,只保留较早的提交信息 exec 执行任意shell命令
  • git merge 和 git rebase的简介

    千次阅读 2018-09-26 11:11:31
    git rebase 这个命令经常被人认为是一种Git巫术,初学者应该避而远之。但如果使用得当的话,它能给你的团队开发省去太多烦恼。在这篇文章中,我们会比较git rebase和类似的git merge命令,找到Git工作流中rebase的...
  • git rebase操作

    千次阅读 2019-07-04 00:03:50
    git rebase 算是git里的高级操作了,他主要用来解决两种情况。 有时候我们对于一个简单的需求提交了多次,这样非常不利于code review,所以我们需要将多次提交合并成一次提交。(即多次commit合并成一次commit) 你...
  • git rebasegit merge 取舍

    千次阅读 2020-04-05 20:14:08
    其中,最常用的命令有 git add、git commit、git push、git pull、git merge。也许你会说你没有用到过git merge,但是你肯定用过git pull,这个命令其实包含了git merge。git pull是git fetch + git merge的组合。 ...
  • git 命令之git rebase 最详细用法 .

    千次阅读 2014-07-16 16:42:22
    git 命令之git rebase 最详细用法 分类: git 2013-04-09 10:51 3502人阅读 评论(1) 收藏 举报 1.出现情况的背景:  当你提交的代码后,管理员发现,您的代码不能提交到服务器上,主要原因在于,你...
  • git的冲突解决--git rebase之abort、continue、skip

    万次阅读 多人点赞 2019-03-26 09:53:57
    git的冲突解决–git rebase之abort、continue、skip 原文转自:http://www.cnblogs.com/chenjunjie12321/p/6876220.html (1)应用实例描述 假设在github或者gitoschina上建立了一个项目,默认分支为master分支,...
  • 想象一下你正在开发一个激进的新功能。这将是很灿烂的但它需要一段时间。您这几天也许是几个星期一直在做这个。...但有一件事情:你开始慢慢意识到,这个疯狂的东西仍需要更多的时间才能真的做好准备被合并回...
  • git 命令之git rebase 用法&git rebase介绍

    千次阅读 2016-12-21 14:52:27
    1.出现情况的背景:  当你提交的代码后,管理员发现,您的代码不能提交到服务器上,主要原因在于,你的commit 中和服务器中的有些commit不再同一时间轴上,即:你的有些commit要插入到服务器中的某些commit...
  • git rebase 理解成是“重新设置基线”,将你的当前分支重新设置开始点。 这个时候才能知道你当前分支与你需要比较的分支之间的差异。 原理:rebase需要基于一个分支来设置你当前的分支的基线,这基线就是当前分支的...
  • git rebasegit fetch 区别

    千次阅读 2017-02-21 19:43:46
    dev分支状态如下: test分支状态如下: 使git merge test之后: ...使用git reset –hard HEAD^和git rebase test之后dev状态: 可见没有新增新的commit且test分支合并到了dev分支 test分支状
  • git rebase原理

    千次阅读 2015-10-28 12:13:39
    git rebase,顾名思义,就是重新定义(re)起点(base)的作用,即重新定义分支的版本库状态。要搞清楚这个东西,要先看看版本库状态切换的两种情况:我们知道,在某个分支上,我们可以通过git reset,实现将当前...
  • git rebase 使用详解

    万次阅读 2015-03-07 22:42:33
    rebase 图示 merge rebase 总结rebase本地两个分支 一个我的分支 test 一个主分支 master 现在我修改的部分要合并到 master 上,可以有两种选择 merge 或者 rebase两者的最后得到的结果是一样的,但是区别是 rebase ...
  • git rebase使用简介

    2020-06-28 17:23:10
    这里我们先不说git提交规范,就单纯这么多次无用的commit就很让人不舒服。可能很多人觉得无所谓,无非是多了一些提交纪录。 然而,并非如此,你可能听过破窗效应,编程也是如此! 二、导致问题 1.不利于代码...
  • git fetch, git pull与git rebase比较

    千次阅读 2017-05-03 15:46:48
    1.git fetch git-fetch,从其他Git库的branch或tag或refs下载对象和引用到本地。 特性: 可以同时操作多个Git库 默认操作Git库origin 操作后更新.git/FETCH_HEAD   使用格式: git fetch [<options&...

空空如也

1 2 3 4 5 ... 20
收藏数 874,557
精华内容 349,822
关键字:

git rebase