前言

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:

The HEAD pointer stays the same.

The MERGE_HEAD ref is set to point to the other branch head.

Paths that merged cleanly are updated both in the index file and in your working tree.

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

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 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.

The recursive strategy can take the following options:

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.

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.

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

Git：真实 merge相关推荐

git如何merge github forked repository里的代码更新?
2019独角兽企业重金招聘Python工程师标准>>> 转自 haojii 发表于2011/08/20 问题是这样的,github里有个项目ruby-gmail,我需要从fork自同 ...
winmerge 保存为html,使用WinMerge作为git的Merge工具
使用WinMerge作为git的Merge工具我比较喜欢使用免费的WinMerge作为diff和merge工具,虽然TortoiseGit也自己带了TortoiseGitMerge工具,但是使用起来 ...
git使用merge合并代码没有生效，提示already up to date
git使用merge合并代码没有生效,提示already up to date. 可以确定两个分支的代码不一致,先切换到主分支,fetch一下,然后pull:在进行合并. git checkout m ...
图解 Git 基本命令 merge 和 rebase
Git 基本命令 merge 和 rebase,你真的了解吗? 前言 Git 中的分支合并是一个常见的使用场景. 仓库的 bugfix 分支修复完 bug 之后,要回合到主干分支,这时候两个分支需要合 ...
Eclipse+git中merge代码时出现conflict（冲突）的问题解决方案
多人合作开发一个项目时,Eclipse中使用git pull更新代码时经常会出现conflict(冲突)的问题,主要是由于多人操作同一个文件导致的. 使用git也没多久,今天终于摸索出一套方法可以解决 ...
Git使用Merge和Rebase
git rebase命令常常因为江湖上关于它是一种Git魔法命令的名声而导致Git新手对它敬而远之,但是事实上如果一个团队能够正确使用的话,它确实可以让生活变得更简单.在这篇文章中我们会比较git r ...
git 只merge部分_[Skill]俩小时掌握多人开发中git的主要用法
前言几个月前看完了git文档,但是在实际开发中对很多git命令的具体影响仍有疑惑,比方说pull.fetch和rebase三个命令和检出位置拎不清. Git - Bookgit-scm.com 安 ...
Git(10)-merge
Merge 1. 无冲突合并 2. 有冲突合并-手动解决 3. git diff in merge 4. 废弃合并 5. 合并策略 merge相关的操作的命令 git checkout master ...
git 的 merge 与 no-ff merge 的不同之处
文章目录参考链接证明参考链接分支管理策略通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息.如果要强制禁用Fast forward模 ...

Git：真实 merge

前言

博客

前言

正文

介绍

合并策略：

参考

Git：真实 merge相关推荐

最新文章

热门文章