git merge的recursive策略和merge-base

git的合并策略总共有3种,一种是resovle,一种是recursive,一种是octopus。其中resolve和recursive适用于合并2个branch,octopus适用于合并3个或者3个以上的branch。对于这3中策略,都需要涉及到merge-base commit,ours commit和theirs commit,即3-way mege。

3-way merge

如下图所示,假设要将branch B合并到branch A,那么branch A的tip commit就是ours commit,branch B的tip commit就是theirs commit,而两个branch的公共commit(即图中有阴影的commit)就是merge-base。合并的时候就是将theirs commit相对于merge-base commit的改变应用到ours commit上,并产生一个新的commit。

但是如果在应用theirs commit相对于merge-base commit的改变的时,在同一区域,ours commit相对于merge-base commit也做了改变,就会产生冲突。举个例子,merge-base commit, ours commit,theirs commit里面都有同一个文件a,如下图所示:

theirs commit相对于merge-base commit的改变是将1,3之间的2修改为5,而ours commit相对于merge-base commit在1,3之间也做了修改,即插入了8,所以合并的时便会出现冲突:

1

++<<<<<<<<<ours

+2

+8

++=========

+ 5

++>>>>>>>>theirs

3

+4

在出现冲突的同时,git会在index中记录merge-base commit,ours commit,theris commit的相关文件,并以1,2,3标识,可以通过git ls-files -u命令查看。

merge-base

merge-base是branch之间的best common ancestor。common ancestor A比另一个common ancestor B better的条件是:B是A的ancestor。因此,一个best common ancestor没有任何better common ancestor。举个例子,如下图所示:

branch A和branch B之间有两个best common ancestor,就是图中加阴影的commit 1和commit 2。又如下图:

此时branch A和branch B的best common ancestor是加阴影的commit 3,而不是commit 1和comit 2,因为commit 3是commit 1和commit 2的ancestor。

利用git merge-base --all可以找出所有的best common ancestor。

recursive策略

merge的recursive 策略就是当两个branch之间有多个best common ancestor的时,git先临时合并这些best common ancestor,然后将这个临时产生的commit作为merge-base来合并branch。如果产生了冲突,git仍然会在index中作记录,也可以通过git ls-files -u命令来查看。

时间: 2024-10-07 23:16:16

git merge的recursive策略和merge-base的相关文章

git两种合并方法 比较merge和rebase

18:01 2015/11/18git两种合并方法 比较merge和rebase其实很简单,就是合并后每个commit提交的id记录的顺序而已注意:重要的是如果公司用了grrit,grrit不允许用merge,所以好像都是用rebase却别讲解,比如:在服务器上的develop分支有多人在开发,你们同时clone或pull下来最新代码,但是开发进度不一样,你在开发一个任务的时候其他人提交了编号为1,2的commit和push,你现在开发完了也要提交,你的提交编号是3,4(注意:编号不代表顺序现实

git remote 仓库命令 rebase 和 merge

git remote add origin https://git.oschina.net/wcms/WCMS.git //添加仓库 git remote 查看当前仓库 git remote remove origin //删除仓库 git push origin  :version  //删除远程分支 git remote 仓库命令 rebase 和 merge

[Git] git revert ( revert commit 和 revert merge)

转载自:http://blog.csdn.net/qinjienj/article/details/7621887 我们难免会因为种种原因执行一些错误的commit / push,git提供了revert命令帮助程序员修复这样的错误. 举个例子,下图是git commit 的历史记录 git revert 命令会通过一个新的commit 来使仓库倒退一个commit,在上例中,如果程序员想要revert 最新的那次commit (Updated to Rails 2.3.2 and edge h

Git中pull对比fetch和merge

本文参考于:http://www.zhanglian2010.cn/2014/07/git-pull-vs-fetch-and-merge/ 使用git fetch和git pull都可以更新远程仓库的代码到本地,但是它们之间还是有区别 git fetch git fetch origin master git log -p master..origin/master git merge origin/master 从远程的origin仓库的master主分支更新最新的版本到origin/mas

git无法pull仓库refusing to merge unrelated histories

http://blog.csdn.net/lindexi_gd/article/details/52554159 本文讲的是把Git在最新2.9.2,合并pull两个不同的项目,出现的问题如何去解决fatal: refusing to merge unrelated histories 我在Github新建一个仓库,写了License,然后把本地一个写了很久仓库上传. 先pull,因为两个仓库不同,发现refusing to merge unrelated histories,无法pull 因为

Git: 聊聊Rebase命令,与Merge的区别

转帖自2015-12-02 lazybios 日拱一卒 相比Merge命令,大家对Rebase要相对陌生一些,Rebase这个命令在<Pro Git book>中被翻译为「衍合」,感觉好别扭,个人感觉无论是从音还是行(为)叫做「变基」要更佳恰当一些. Rebase的大致流程 Step1: 场景假定 你基于一个远程分支origin创建了一个mywork的分支 git checkout -b mywork origin Step2: 进行开发 创建好分支后,你就开始兢兢业业的在mywork分支上开

android studio提交到开源git时出现:fatal: refusing to merge unrelated histories的解决办法

创建本地库和fetch远程分支这些前面的步骤这里略过.可以自行百度. 解决办法: 1.cmd进入项目的根目录. 2.执行下面的命令:git pull origin master --allow-unrelated-histories.可以提交成功. 3.再次push. 有其它的好办法,欢迎建议. 原文地址:https://www.cnblogs.com/xiangxinhouse/p/8254120.html

【转】git场景:git chekout分支遇到问题--need merge

解决步骤: 在master上, 1.git add . 2.git commit 3.新建分支,并且checkout到此分支,重新提交: 原文:https://www.cnblogs.com/UniqueColor/p/6594942.html 原文地址:https://www.cnblogs.com/coreLeo/p/11833880.html

Pandas中DataFrame数据合并、连接(concat、merge、join)之merge

二.merge:通过键拼接列 类似于关系型数据库的连接方式,可以根据一个或多个键将不同的DatFrame连接起来. 该函数的典型应用场景是,针对同一个主键存在两张不同字段的表,根据主键整合到一张表里面. merge(left, right, how='inner', on=None, left_on=None, right_on=None, left_index=False, right_index=False, sort=True, suffixes=('_x', '_y'), copy=Tr