Git:真实 merge

前言

Git:真实 merge 是一种 merge 的方式,除去真实 merge,肯定还有不真实的 merge,就是那种 FF (FAST-FORWARD MERGE)的 merge,这个 FF,曾经出现在在收音机上,出现在录像机上,出现在视频播放器上,就是快进的意思。

博客

IT老兵驿站

前言

这里准备碎片化地去解读和理解 Git 的一些功能。关于 git-merge 的总结一直没有做,但是几乎每天都会遇到 git-merge,而且会遇到很多随着 merge 而产生的问题,所以只好碎片化地去做一做整理。

正文

git-merge 有两种 merge 方式,ff 方式和 true merge 方式,关于 ff 的方式,另外一篇文章有讲过,这里不再赘述,这里整理一下 true merge,真实 merge。

介绍

先摘录一段:

TRUE MERGE
Except in a fast-forward merge (see above), the branches to be merged must be tied together by a merge commit that has both of them as its parents.

真实 merge 是真的去 merge 一下,而不是像 ff 那样,只是把一个 commit 放过来,从这个角度来说,ff 不是有点像 cherry-pick 吗?

A merged version reconciling the changes from all branches to be merged is committed, and your HEAD, index, and working tree are updated to it. It is possible to have modifications in the working tree as long as they do not overlap; the update will preserve them.

一个 merge 的版本融合了(reconcile 的意思是调节,放在这里有点不好理解,所以解释为融合)所有要被 merge 的分支的改变,并且会被提交,这样你的 HEAD、index、working tree 都会被更新。

When it is not obvious how to reconcile the changes, the following happens:
</br>
The HEAD pointer stays the same.
</br>
The MERGE_HEAD ref is set to point to the other branch head.
</br>
Paths that merged cleanly are updated both in the index file and in your working tree.
</br>
For conflicting paths, the index file records up to three versions: stage 1 stores the version from the common ancestor, stage 2 from HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with git ls-files -u). The working tree files contain the result of the "merge" program; i.e. 3-way merge results with familiar conflict markers <<< === >>>.

3路 merge,公共祖先、HEAD、MERGE_HEAD(是指另外那个分支的 HEAD) 这三个方面来 merge。

这里是三个版本的关系,公共祖先的版本、HEAD(本地仓库的版本)、MERGE_HEAD(另外一个分支想要merge过来的版本),所以叫3-way merge,三路合并。

If you tried a merge which resulted in complex conflicts and want to start over, you can recover with git merge --abort.

当你搞不定了,使用 git merge --abort 回滚吧。

关于HEAD、index、worktree、local repository、remote repository的关系,请参考这里,这个挺重要,随后要整理一下。

合并策略:

MERGE STRATEGIES
</br>
The merge mechanism (git merge and git pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X<option> arguments to git merge and/or git pull.

git merge 和 git pull 命令使用的 merge 机制允许通过 -s 选项后面的 merge 策略被选择。

resolve
This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.

recursive
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies. This is the default merge strategy when pulling or merging one branch.
</br>
The recursive strategy can take the following options:
</br>
ours
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.
</br>
This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.
</br>
theirs
This is the opposite of ours; note that, unlike ours, there is no theirs merge strategy to confuse this merge option with.
......

使用-X<option>参数,可以指定合并策略,上面摘录了两种,一种是 resolve,一种是recursive,第一种策略看上去似乎是可以自动解决冲突,第二种是 Git 默认的 merge 策略,会产生一些少量的冲突,而不会进行错误的合并,它还有几个选项,就是合并时,只选择本地的(ours),或者只选择别人的(theirs)。

参考

https://git-scm.com/docs/git-merge
https://stackoverflow.com/questions/3689838/whats-the-difference-between-head-working-tree-and-index-in-git

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,590评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,808评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,151评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,779评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,773评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,656评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,022评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,678评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,038评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,756评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,411评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,005评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,973评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,053评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,495评论 2 343

推荐阅读更多精彩内容