Visual studio projects, as opposed to makefiles or other projects I know, have some quirks:

  • The directory structure of the project has no real connection to actual directory structure - all directories are purely virtual - this makes it harder to re-add mass of files while keeping directory structure
  • The project consists of rather complex XML, that file contains everything from files to compiler settings

Now whenever I merge branches, I have conflict on the project files, because everyone inadvertently changes them as they operate over the project. Often the changes happen in such ways that the merge tool does not even recognize conflict properly. In those cases, files end up missing in the project, outdated settings reappear and so on.

Our project is 2010 C++ solution consisting of five separate sub-projects.

Are there any strategies that would have low impact on the development process, but would alleviate problems caused by merging project files?

  • "in such ways that the merge tool does not even recognize conflict properly" - never encountered such a situation by myself Which programming languages and project types are you using mainly?
    – Doc Brown
    Jan 18, 2017 at 19:17
  • 1
    How does project language affect what does meerge tool to XML files? The problem is that certain changes are automatically resolve and not marked as conflict. Jan 18, 2017 at 19:51
  • C++ project files are somewhat different from other .NET language files, in general more complex.
    – Doc Brown
    Jan 18, 2017 at 20:18
  • 1
    Found this article by a quick google search: haacked.com/archive/2014/04/16/csproj-merge-conflicts Do you have a configuration like *.csproj merge=union in your .gitattributes?
    – Doc Brown
    Jan 18, 2017 at 20:25
  • @DocBrown No I don't. But I read the article and maybe enforcing conflicts on those files is what I need. I wonder if I could enforce behavior they describe on any file type I chose. Jan 24, 2017 at 11:28

3 Answers 3


I find there are a couple things you can do to virtually eliminate this problem.

  1. More projects. Spreading code changes over more projects means less chance of a merge conflict and simpler projects files when you do get them.

  2. Build all your branches on the build server. This picks up build failures due to people forgetting to save the project when they add a file. Before they merge in their branch.

  3. Make everyone use the same version of visual studio

  4. Make sure as many settings as possible go in the .csproj.user file rather than .csproj and exclude this from source control.


This is a classic case for continuous integration where everybody checks into 1 branch.

  1. Developers should be able to resolve basic conflicts correctly, I'm assuming your conflicts are great in scope to cause what you describe.

  2. When checking into the same branch while working on the same proj file, with everybody checking in at least once a day, the conflicts will still occur, but 1-2 at a time typically and that will make them manageable.

You should also apply Ewan's suggestions on top of this.


Writing your own merge tool may be a feasible solution. Git integration is fairly straight forward, https://www.git-scm.com/docs/git-mergetool#_options:

  • Set tool path and arguments
  • Tool locate files to merge and result file by environment variables
  • Tool decides for merge success or failure (your preference)

If writing your own tool you can make decisions based on whether elements are order dependent or independent (similar to .gitattributes merge=union, but only when sensible), perhaps deduce rename operations, break down line changes into smaller components. Sky is the limit.

And should you make it a successful open source project, you will become legend.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.