前言

Git：真實 merge 是一種 merge 的方式乘综，除去真實 merge裆装，肯定還有不真實的 merge崇棠，就是那種 FF （FAST-FORWARD MERGE）的 merge涛贯，這個 FF厕氨，曾經(jīng)出現(xiàn)在在收音機上坝辫，出現(xiàn)在錄像機上篷就，出現(xiàn)在視頻播放器上，就是快進的意思近忙。

博客

IT老兵驛站竭业。

前言

這里準備碎片化地去解讀和理解 Git 的一些功能。關于 git-merge 的總結一直沒有做及舍，但是幾乎每天都會遇到 git-merge未辆，而且會遇到很多隨著 merge 而產(chǎn)生的問題，所以只好碎片化地去做一做整理锯玛。

正文

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 的意思是調(diào)節(jié)捷兰，放在這里有點不好理解立叛，所以解釋為融合）所有要被 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>參數(shù)当悔，可以指定合并策略，上面摘錄了兩種踢代，一種是 resolve盲憎，一種是recursive，第一種策略看上去似乎是可以自動解決沖突胳挎，第二種是 Git 默認的 merge 策略饼疙，會產(chǎn)生一些少量的沖突，而不會進行錯誤的合并，它還有幾個選項窑眯，就是合并時屏积，只選擇本地的（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