Git Lab 從 origin master 拉取 -（遠程存儲庫），我如何解決合並沖突？

Question

我在文件中有很多合並沖突，我認為這些沖突不一定重要。 有沒有辦法從遠程存儲庫中提取並忽略這些文件？

一些合並錯誤如下：

CONFLICT (content): Merge conflict in FoodSpot/obj/Debug/DesignTimeResolveAssemblyReferencesInput.cache
Auto-merging FoodSpot/bin/FoodSpot.pdb
CONFLICT (content): Merge conflict in FoodSpot/bin/FoodSpot.pdb
Auto-merging FoodSpot/bin/FoodSpot.dll
CONFLICT (content): Merge conflict in FoodSpot/bin/FoodSpot.dll
Auto-merging FoodSpot/FoodSpot.csproj
CONFLICT (content): Merge conflict in FoodSpot/FoodSpot.csproj
Auto-merging FoodSpot/Additional_Scripts/distributor-script.js
Auto-merging .vs/FoodSpot/v16/.suo
CONFLICT (content): Merge conflict in .vs/FoodSpot/v16/.suo
Automatic merge failed; fix conflicts and then commit the result.

Answer 1

有沒有辦法從遠程存儲庫中提取並忽略這些文件？

這個問題很容易回答：不。 ¹但這不是真正正確的問題！

我在文件中有很多合並沖突，我認為這些沖突不一定重要。

當“您”和“他們”對已匹配為“同一文件”的文件進行不同更改時，就會發生合並沖突。 如果您想保留其中一個或多個文件的版本，或使用其中一個或多個文件的版本，這很容易做到。 這就是合並沖突的解決方案：您已經通過丟棄一個版本並批發另一個版本來“修復”沖突。

非常確定這是解決沖突的正確方法，因為從現在開始，Git 將相信這是解決沖突的正確方法。

這是正在發生的事情的說明，以及哪些 Git 命令將解決沖突：

          I--J   <-- yourbranch (HEAD)
         /
...--G--H
         \
          K--L   <-- theirbranch

圖中的每個大寫字母都代表一個巨大的、丑陋的 Git 哈希 ID，因此代表現在在您的存儲庫中的提交。 請記住，每個提交都包含 Git 知道的每個文件的完整快照——因此提交G有一個FoodSpot/bin/FoodSpot.pdb的副本，提交H有一個副本，提交I 、 J 、 K和L . 每個提交都有這個文件的副本。 （幸運的是，相同的副本都進行了重復數據刪除，因此它們不會占用太多空間。）

（注意：這里的theirbranch實際上可能是origin/yourbranch或其他名稱origin/yourbranch不關心名稱，而是關心提交。名稱僅用於定位提交。）

您在此處遇到合並沖突的原因是H中此文件的副本與J的副本不同，即您對分支上的此文件進行了一些更改。 同時，這個文件在H的副本也與L的副本不同，即他們在他們的分支上對該文件進行了一些更改。 Git 無法組合這兩組更改，以便將組合的更改應用於H中的文件副本。

Git 需要您向 Git 提供此文件FoodSpot/bin/FoodSpot.pdb的正確副本，該副本將進入合並提交以結束合並過程：

          I--J
         /    \
...--G--H      M   <-- yourbranch (HEAD)
         \    /
          K--L   <-- theirbranch

Commit M包含最終的合並結果。

如果您希望新提交M的FoodSpot/bin/FoodSpot.pdb副本與提交J中的副本匹配，請告訴 Git：

git checkout HEAD -- FoodSpot/bin/FoodSpot.pdb

如果您希望新提交M的FoodSpot/bin/FoodSpot.pdb副本與其提交L中的副本匹配，請告訴 Git：

git checkout MERGE_HEAD -- FoodSpot/bin/FoodSpot.pdb

這兩個操作都會替換該文件的工作樹副本和 Git 的索引副本，並在此過程中將沖突標記為“已解決”。

---

¹實際上，您可以通過.gitattributes設置合並驅動程序。 不要這樣做！ 這是一個陷阱。 如果您更改了文件而他們沒有更改，並且您設置了一個合並驅動程序以采用“他們的”版本，則該驅動程序將不會觸發。 使用--no-commit手動進行合並，即使沒有沖突，也要確保使用“他們的”文件版本。

---

至少其中一些文件可能根本不應該提交

上面的文件名之一以.dll結尾。 DLL 通常是構建產品，而不是源文件。 一個里面有obj ； 這些通常是構建產品。 有幾個里面有bin ，Git 不太擅長處理二進制文件。

但是，從意外提交的存儲庫中刪除構建產品存在問題。 由於無法更改現有提交，如果您進行缺少文件的新提交，則在具有文件的舊提交和沒有文件的新提交之間進行任何比較，將文件顯示為已刪除（舊->新）或添加（新->舊）。

這是否是一個問題，如果是，你應該怎么做，是不同的問題，但 Git 永遠不能自己合並二進制文件。 Git 的合並代碼只能理解——好吧，認為它理解——純文本，然后只能逐行。 純文本 XML 結構文件將被 Git 錯誤合並。 如果你有這樣的文件，千萬不要相信 Git 的合並，即使 Git 認為沒有任何沖突。 確保您測試或檢查每個文件。