此處有3張圖，分別為2個branch：master和follower；

這是master！劃重點了啊！這個是master裡面的檔案，和follower沒有關係的

這個！這個是follower！看清了！follower裡面的檔案，master還不認識它呢！

第三張圖就是merge之後的檔案（會出現在其中一個branch裡面，看你選擇哪個了）：

各位可以看到被綠色圈起來的“新的核對點”，為什麼他只出現了一次呢？

是因為在兩個文字中，這個“核對點”是完全一致的，於是GitHub就不再更改位置，

將其作為一個核對點，而將上下文中出現的有所不同 的地方以對比的形式表現出來。

而merge的時候，

【示例中出現的分割線是之前筆者嘗試時候出現的】

GitHub會尋找兩個檔案中完全一致的文字資訊作為核對點，求同存異

以上就是單純的merge，沒有conflict攪局。

這是一個分支中檔案為另一個分支的子集的情況，可以看到，我們在一個檔案中添加了另一個檔案沒有的東西。所以可以自動merge，這對計算機來說是非常簡單的。

conflict

但是如果兩個檔案不是成為子集的關係呢？

這時候，系統就會向你求救：

X Can’t automatically merge.

可以說這就非常尷尬了，這怎麼辦呢？

首先，GitHub不會輕易修改你的任何一份程式碼，因為手心手背都是肉，GitHub也不知道哪個是你需要的。

GitHub兩手一攤：“使用者，你看怎麼辦吧，你給我這兩個同等重要但是又互相沖突的【conflict】文件，你想要哪個？我看你就是在為難我胖虎。。。”

我：“emmmm...我改就完了唄！”

方案：刪除掉其中一份文件的衝突內容，使得一個文件是另一個文件的子集。

下圖為GitHub的甩鍋圖。

而在最新的GitHub網站上，這些操作都可視化了。

即使你不能merge兩個有衝突的文件，但是你還是可以記錄下來，以供master與follower互相交流。

系統會提示你：“現在你不能merge文件，但是你可以把merge的請求提交上去呀！到時候人家master分支的所有者看到你的請求，再做定奪。”

我說好。

於是我把新的分支的資訊pull request，這樣有一天master看到了我的提交資訊——

於是，我（follower）和他（master）進行了親切友好的會談。