cherry-pick,revert和rebase使用的3-way合并策略

  git中的cherry-pick,revert和rebase都使用的是3-way合并策略,下面就来看看这3个方法使用的merge-base,ours和theirs分别是什么。

cherry-pick

  假如有如下的提交历史,使用命令git cherry-pick alt(当前branch是master),那么merge-base就是加阴影的commit 1,ours就是加阴影的commit 3,theirs就是加阴影的commit 2。

revert

  假如有如下提交历史,使用命令git revert master~2,那么merge-base就是加阴影的commit 1,ours就是加阴影的commit 3,theirs就是加阴影的commit 2.

rebase

  假如有如下提交历史,每一个提交都向一个文件a里面增加一行,比如commit 1向文件a里面写入1,commit 2向文件a里面写入2,依次类推。使用命令git rebase --onto master alt1 alt2时,merge-base,ours,theirs分别是什么呢?

当使用rebase命令时,git如做如下3件事:

1 确定要rebase的commit是什么,这里要rebase的commit就是alt1..alt2。alt1..alt2表示从alt2可reachable的commit当中减去从alt1同样可以reachable的commit,这里就是commit 10,commit11,commit12;

2 使用一个匿名branch指向alt2

3 将alt2 reset到新的base,即master

如下图所示:

接下来git会依次将commit 10,commit 11, commit 12 rebase到新的alt2上。如果在rebase commit 10发生了冲突,那么merge-base就是commit 6,ours就是alt2指向的commit 5,theirs就是commit 10。如果commit 10 rebase成功后的commit记为commt 10’(此时alt2会指向commit 10‘),接下来rebase commit 11如果也发生了冲突,那么merge-base同样是commit 6,ours是commit 10‘,theirs是commit 11。当rebase完成之后如果所示:

由于rebase之后commit 10,commit 11,commit 12没有被任何分支引用,它们最后会被git移除。

rebase有一个特殊的情况如下图所示:

如果运行命令git rebase --onto master alt1 alt2,要被rebase的commit应该是alt2上的commit 7,commit 8, commit 10,但是由于alt1(在git rebase --help中,alt1被称为upstream),上面也有commit 7和commit 8,它们对文件a所做的修改时一样的,这时,git只会rebase alt2上的commit 10,相应merge-base也会成为alt1上的commit 8,最后的结果如下图,rebase完成之后,虚线框中的commit 7,commit 8, commit 10同样会被git移除。

时间: 2024-08-29 00:05:40

cherry-pick,revert和rebase使用的3-way合并策略的相关文章

git merge / rebase 分支的新建与合并

merge https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6 关键指令 git checkout -b xxx       新建分支 git branch -d xxx       删除分支 git merge  xxx          合并分支 git checkout xxx 切换分支 关

git合并分支上指定的commit

merge 能够胜任平常大部分的合并需求.但也会遇到某些特殊的情况,例如正在开发一个新的功能,线上说有一个紧急的bug要修复.bug修好了但并不像把仍在开发的新功能代码也提交到线上去.这时候也许想要一个只合并指定某些 commit 的功能. 假设分支结构如下: dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master] 76cada-62ecb3-b886a0[feature] 再假设 62ecb3 的提交修复了bug,这时候可以用cherry pic

merge vs rebase

git rebase和git merge设计的初衷是解决相同的一件事, 即把一个分支合并到另外一个分支--只是他们两个处理的方式非常不一样. 当你在一个特定的分支开发新功能, 团队的其它成员在master分支工作提交了新的commit. 这个项目的历史就会分叉. 现在假设master中的这个新的commit和你在其它分支中开发的新功能相关, 你想在你的feature分支中包含这个commit, 你有两种选择:merge和rebase. merge 最简单的办法就是merge master分支到你

git使用之rebase合并提交

git使用之rebase合并提交技术 maybe yes 发表于2015-03-15 22:43 原文链接 : http://blog.lmlphp.com/archives/88/The_use_tutorial_of_git_rebase_to_merge_multiple_commits_as_a_submit  来自 : LMLPHP后院 对于版本控制系统 GIT ,一直没有深入研究,只是从日常使用方面入手,能解决平常使用出现的问题就可以了.GIT 的版本控制,有三种后悔方式:reset

【译文】Git merge 和 Git rebase比较

[译文]Git merge 和 Git rebase比较 原创: 胡江华 胡同学和朋友们的成长日记 2017-03-22 git rebase 这个命令经常被人认为是一种Git巫术,初学者应该避而远之.但如果使用得当的话,它能给你的团队开发省去太多烦恼.在这篇文章中,我们会比较git rebase和类似的git merge命令,找到Git工作流中rebase的所有用法. 概述 你要知道的第一件事是,git rebase 和git merge 做的事其实是一样的.它们都被设计来将一个分支的更改并入

闲谈 git merge 与 git rebase 的区别

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

巧用 git rebase 合并多个 commit。

一.为什么需要合并多个 commit 呢? 有时候,我们开发一个功能. 修修补补 commit 了很多次,过多的 commit 会显得很复杂. 不够直观,不能比较清晰查看那些 commit 是对应的那个功能. 所以,在这种情况下.我们需要整理一下 commit 的记录,让我们更好的管理提交记录. 二.具体合并多个 commit 的流程. 1.development 分支有四次 commit ,然后我准备合并 "add a.php" 和 "add b.php" 的两次

[Git] Rebase - 使用 Interactive 模式来精简 commit 纪录

避免过多 commit 纪录造成线图繁杂 透过 Rebase Interactive Mode?来将 commit log 进行精简 前言 在开发的过程中,会随着各种原因将代码提交至 local repository 中,并且在完成最终功能的开发后,会将 local 的变动 push 到 remote repository 中:此时为了避免过多无特别意义的 commit 纪录造成线图的繁杂,因此会透过各种方式来将 commit log 进行精简,其中处理方式多为 git reset 或 git

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