Git Lab pull from origin master - (remote repository), how do i resolve Merge Conflicts?

Question

I have a lot of merge conflicts in files that i don't find to be necessarily important. Is there a way to pull from the remote repository and ignore those files?

Some of the merge errors are as follows:

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

Is there a way to pull from the remote repository and ignore those files?

This question is easy to answer: no. ¹ But that's not really the right question!

I have a lot of merge conflicts in files that i don't find to be necessarily important.

A merge conflict occurs when "you" and "they" have different changes to files that have been matched-up as "the same file". If you want to keep your version of one or more of those files, or take their version of one or more of those files, that's easy to do. That's the resolution to the merge conflict: you've "fixed" the conflict by throwing out one version and taking the other wholesale.

Be very sure this is the right way to resolve the conflict, because from now on, Git will believe that this was the right way to resolve the conflict.

Here's an illustration of what's going on, and what Git commands will resolve the conflict:

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

Each uppercase letter in the diagram here stands in for a big ugly Git hash ID, and therefore represents a commit that is now in your repository. Remember that each commit holds a full snapshot of every file that Git knew about—so commit G has a copy of FoodSpot/bin/FoodSpot.pdb , and commit H has a copy, and so do commits I , J , K , and L . Every commit has a copy of this file. (Fortunately, the identical copies are all de-duplicated, so they don't take that much space.)

(Note: theirbranch here might actually be origin/yourbranch or some other name. Git doesn't care about the names , but rather about the commits . The names simply serve to locate the commits.)

The reason you got a merge conflict here is that the copy of this file in H differs from the copy in J , ie, you made some changes to this file on your branch. Meanwhile, the copy of this file in H also differs from the copy in L , ie, they made some changes to this file on their branch. Git was unable to combine these two sets of changes so as to apply the combined changes to the copy of the file that is in H .

What Git needs from you is for you to provide, to Git, the correct copy of this file FoodSpot/bin/FoodSpot.pdb that will go into the merge commit that you will make to conclude the merge process:

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

Commit M contains the final merge results.

If you'd like the copy of FoodSpot/bin/FoodSpot.pdb in new commit M to match the copy in your commit J , tell Git:

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

If you'd like the copy of FoodSpot/bin/FoodSpot.pdb in new commit M to match the copy in their commit L , tell Git:

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

Both of these operations replace both your work-tree copy of that file, and Git's index copy, and in the process, mark the conflict as "resolved".

---

¹ Actually, you can set up a merge driver via .gitattributes . Don't do it! It's a trap. If you have a file that you changed and they didn't , and you set up a merge driver to take "their" version, the driver won't fire. Do the merge manually with --no-commit and, even though there is no conflict, make sure you take "their" version of the file.

---

At least some of these files should probably never have been committed at all

One of the file names above ends with .dll . DLLs are usually build products , not source files. One has obj in it; these are usually build products. Several have bin in them, and Git is not very good at dealing with binaries.

There's a problem with removing build products from repositories in which they were accidentally committed, though. Since existing commits cannot be changed, if you make new commits that lack the files, any comparison between the old commits that have the files, and the new ones that don't, show the files as being removed (old->new) or added (new->old).

Whether this is a problem, and if so, what you should do about it, are separate questions, but Git can never merge binary files on its own. Git's merge code only understands—well, thinks it understands—plain text, and then only line-by-line. Plain-text XML-structured files will be mis-merged by Git. If you have such files, never trust Git's merge, even if Git thinks there aren't any conflicts. Make sure you test or check each file.