Git Lab从原始主机-远程存储库中拉出，我该如何解决合并冲突？ 至少其中一些文件可能根本不应该提交

如何解决Git Lab从原始主机-远程存储库中拉出，我该如何解决合并冲突？ 至少其中一些文件可能根本不应该提交

我在文件中有很多合并冲突，但我认为这些冲突并不重要。有没有办法从远程存储库中提取文件并忽略这些文件？

一些合并错误如下：

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.

解决方法

有没有办法从远程存储库中提取文件并忽略这些文件？

这个问题很容易回答：不。 ¹ 但这不是一个正确的问题！

我发现文件中有很多合并冲突，但我认为这些冲突不一定很重要。

当“您”和“他们”对匹配为“同一文件”的文件进行不同更改时，发生合并冲突。如果您要保留一个或多个这些文件的版本，或者获取一个或多个这些文件的版本，这很容易做到。这就是合并冲突的解决方案：您已经抛出了一个版本并批量批发了另一个版本，从而“解决了”冲突。

请务必确保这是解决冲突的正确方法，因为从现在开始，Git将相信这是解决冲突的正确方法。

这里是正在发生的事情的说明，以及哪些Git命令可以解决冲突：

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

图中的每个大写字母代表一个丑陋的Git哈希ID，因此代表了现在位于您的存储库中的提交。请记住，每个提交都拥有Git知道的每个文件的完整快照-因此，提交G具有副本FoodSpot/bin/FoodSpot.pdb，提交H具有副本，提交{{ 1}}，I，J和K。 每个提交都有此文件的副本。 （幸运的是，相同的副本都已重复数据删除，因此不会占用太多空间。）

（注意：L实际上可能是theirbranch或其他名称。Git不在乎名称，而是在 commits 。这些名称仅用于查找提交。）

此处出现合并冲突的原因是origin/yourbranch中此文件的副本与H中的副本不同，即，您对此做了一些更改文件在您的分支上。同时，此文件在J 中的副本也与H中的副本不同，即他们在他们的分支。 Git无法合并这两组更改，因此无法将合并的更改应用于L中的文件副本。

Git需要您提供的文件H的正确副本提供给Git，该副本将进入合并提交您将完成合并过程：

FoodSpot/bin/FoodSpot.pdb

提交 I--J / \ ...--G--H M <-- yourbranch (HEAD) \ / K--L <-- theirbranch 包含最终合并结果。

如果您希望新提交M中的FoodSpot/bin/FoodSpot.pdb副本与您的提交M中的副本相匹配，请告诉Git：

J

如果您希望新提交git checkout HEAD -- FoodSpot/bin/FoodSpot.pdb 中的FoodSpot/bin/FoodSpot.pdb副本与他们的提交M中的副本匹配，请告诉Git：

L

这两个操作都替换了该文件的工作树副本和Git的索引副本，并在此过程中将冲突标记为“已解决”。

---

¹ 实际上，您可以通过git checkout MERGE_HEAD -- FoodSpot/bin/FoodSpot.pdb 设置合并驱动程序。别做！这是一个陷阱。如果您有一个您已更改而他们没有的文件，并且将合并驱动程序设置为采用“其”版本，则该驱动程序将不会启动。用.gitattributes手动进行合并，即使没有冲突，也请确保使用文件的“其”版本。

---

至少其中一些文件可能根本不应该提交

以上文件名之一以--no-commit结尾。 DLL通常是 build产品，而不是源文件。其中有.dll；这些通常是构建产品。其中一些包含obj，而Git不太擅长处理二进制文件。

但是，从存储库中删除意外生成的构建产品存在问题。由于现有提交无法更改，因此，如果您使 new 提交的文件 lack 提交，则包含文件的旧提交与不包含文件的新提交之间的任何比较，将文件显示为已删除（旧->新）或已添加（新->旧）。

这是否是一个问题，如果是这样，那么您应该采取的措施是单独的问题，但是Git永远无法自行合并二进制文件。 Git的合并代码只能理解-好吧，认为它可以理解-纯文本，然后只能逐行显示。纯文本XML结构的文件将被Git误合并。如果您有这样的文件，即使Git认为没有任何冲突，也不要相信Git的合并。确保测试或检查每个文件。