1. 程式人生 > >[非命令列操作]GitHub中的merge與conflict

[非命令列操作]GitHub中的merge與conflict

此處有3張圖,分別為2個branch:master和follower;

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


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


第三張圖就是merge之後的檔案(會出現在其中一個branch裡面,看你選擇哪個了):


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

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

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

而merge的時候,

會把母集(之前不是說一個檔案是另一檔案的子集嘛)獨有的資訊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)進行了親切友好的會談。