How to properly deal with merges when doing a GIT PULL within Visual Studio

Question

I can't make GIT for TFS properly work within Visual Studio when dealing with merges. Basically every merge operations that occurs when I pull the last version of the code is a nightmare.

I'm specifically talking about merges that occur when pulling someone's else code from the same branch (i.e. I'm not talking about scenarios involving multiple branches).

I'm also specifically talking about the built-in GIT plugin of Visual Studio, so please do not suggest to execute command line commands that I'm aware of (such as rebase) if there is another solution from within the IDE ("you can't" would be a valid answer, though).

Here's how to reproduce the issue:

• there are two developers, A and B, working on the same branch
• developer A pushes some commit that modifies files F1 and F2
• developer B modifies files F1 and F3
• developer B commits modifications on F1 and F3
• developer B does a pull: Visual Studio detects a conflict on file F1 (which is expected)
• developer B resolves the conflict on F1

Now here's the issue: all files F1, F2 and F3 are in the modified state for B. Why? Developer B only modified files F1 and F3. I don't see a valid reason for F2 to be in the modified state, because B did not modify it.

I understand that locally the F2 file is not the same as before the pull, but the problem is that B basically can't review his changes on F1 and F3 before pushing, because everyone else's work (in the simplified case above, on F2) also appears in his list of changes.

In our real world scenarios, there are multiple developers working on the same branch, and every merge is a major failure in the branch history: Visual Studio basically shows a bunch of 50-or-so modified files for every merge (when the developer only modified 1 or 2 files).

This issue always occurs with an up-to-date Visual Studio 2013. Visual Studio 2015 seems clever enough to not show F2 as modified, but not always.

How to fix this behavior? Currently GIT is a PITA to use within Visual Studio because of that.

---

EDIT:

Here's a visual example. On the left, the history as shown within VS 2013: plenty of modified files. On the right, the very same history (same repository, same machine, same commit...etc.) as shown within VS 2015. Obviously VS 2015 shows something different and slightly better (I only see my changes). Do note this doesn't always work that way, sometimes VS 2015 shows files I didn't modify, just like VS 2013 does.

This question was about this behavior when I'm about to push the result of a merge, but it's exactly the same when I simply view the history of a old merge, as shown below:

The questions are:

• is this a bug?
• if not, is this documented?
• in any case, how am I supposed to work with GIT, especially with VS 2013, in regards to the inconsistency as shown above?

Answer 1

You only need to understand how git works.

When you say:

developer B does a pull: Visual Studio detects a conflict on file F1 (which is expected)

That's where you're wrong. Git detects conflicts and can therefore not perform the merge. (Even if you are merging from the "same" branch, what git is doing is create a merge commit to tape these too branches together).

When this happens, git shows you all the differences brought by both branches. You can git add (or whatever it's called in visual studio) all files without conflict, they will be part of the "merge commit".

The only thing you need to do is fix the conflicts where they are marked and let the rest but as is and create the merge commit.

To summarize, when a merge fails, you get to see both changes and conflicts. Just focus on fixing the conflicts and let the regular changes be as they are.