# Outline
一、論述
A、待敘項目

# TL;DR
...

# Updated
2019-10-06: 更新標題文章結構

在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。

一、論述

今天來聊聊 Git Merge 背後的原理吧。剛好今天有處理到 Revert 後想重新 Merge 卻顯示「Already up to date」的案例，我想是一個不錯的研究契機。

Git 合併時，有分為快進模式（ Fast-Foward）與非快進模式。在不特別設置參數時，只要當前分支 A 的 HEAD 要將其某分支 B 併進來，而 A 分支是 B 的祖先節點的話，就會啟用快進模式，將 A 分支的位置直接快進到 B 分支的位置，而不會另外建立 Merge Commit 節點。嚴格來說這不太算是合併。

當 A 分支不是 B 的祖先節點的話，就會啟用正常的合併，在合併後會建立額外的 Merge Commit 節點。在合併上會有幾種策略，這邊先只提兩種，其他的可以參見文件Git - merge-strategies 。

• resolve：三路合併（three-way merge），有共同祖先時使用。

• recursive：遞歸三路合併（Recursive three-way merge），沒有共同祖先時使用。

在提及三路合併前，不如先聊聊兩路合併。兩路合併就是只比對兩個節點是否有差異，若有差異就會拋出衝突。但是這樣的話會太容易有衝突，於是才需要三路合併。

三路合併與二路合併最大的不同就是會多加這兩路的共同祖先去比對，如果 A 路和祖先是一樣的，而 B 路有變化，那就會選擇接受 B 路的變化，而不會拋出衝突。但若 A 和 B 都有變化、與祖先不同，那就會拋出衝突給開發者自行判斷。

A、待敘項目

• 介紹二路合併
• 畫出示意圖
• 介紹 Merge 三個分支以上合併的模式