意外的合併衝突

所以我有這個簡單的文件有3條線路：意外的合併衝突

some 
random 
words

第一合流測試

我創建的原始狀態的文件兩個不同的分支在頂部這個帖子來自高手。我創建分支merge1，將第一行從some更改爲will。我創建的分支merge2將第3行從words更改爲work。我將merge1首先合併到merge2秒，並且一切正常。

第二合流測試

我創建了兩個不同的分支與這個帖子從主頂部的原始狀態的文件。我創建分支merge1，將第一行從some更改爲doesnt。我創建了分支merge2，將第2行從random更改爲work。我首先合併了merge1，但是當我嘗試合併時merge2出現了衝突錯誤，我並不期待。

當我打開該文件，這是我所看到的：

<<<<<<< HEAD 
doesnt 
random 
======= 
some 
work 
>>>>>>> merge2 
words

我不明白的是，爲什麼merge2顯示第一行some因爲merge2並沒有改變該行。具有諷刺意味的是SVN處理得很好。

我在這裏錯過了什麼嗎？爲什麼我可以在同一個提交中創建2個不同的分支，修改小文件的不同行，但不能改變連續的行？

來源

2014-09-20 ryanzec

就我個人而言，我發現默認的conflictstyle完全不可讀。試試'git config --global merge.conflictstyle diff3'。這可能會更有意義。還要記住，通過應用補丁合併工作（認爲統一的差異格式），這意味着在這樣一個小測試中，可能沒有足夠的未改變的上下文線來確定需要更改的內容。 – 2014-09-20 21:20:59

感謝關於衝突風格的提示，它不經意間給出了更多信息，以便就如何處理衝突做出更明智的決定。我也理解文件的小範圍，最初在6000行文件上有問題，但是這對於stackoverflow會更好。 – ryanzec 2014-09-20 21:51:43

基礎上使用Git開發一些猜測...

的變化是基於他們的環境跟蹤。如果你看一下比較差異merge2的承諾，這將是這個樣子：

some 
-random 
+work 
words

當您嘗試合併成merge1修改的文件，它無法找到錨點「一些」。因此，它需要問你如何着手。而修改非連續行時，它仍然可以在文件中找到某個位置來錨定需要應用的更改。

另外，請記住，git是爲了跟蹤代碼的變化。在合併時，它傾向於謹慎，因爲最好讓用戶找出合併，而不是自動合併並以某種非顯而易見的方式破壞代碼。

來源

2014-09-20 00:21:38 Coeffect

關於代碼更改和破壞的好處...這使得SVN將自動合併這一事實只是一個小小的可怕！ :) – Wildcard 2016-03-17 06:40:02

意外的合併衝突

回答

相關問題