Microsoft just made it easier for us developers to tackle git conflicts.
So instead of dismissing that all important notification that says “A Visual Studio Update is available” – today I implore you to give it a click, download it, and install it 😉
..you’ll be pleasantly surprised to learn that as of 10th November 2020 – a new item has been added to the top of the context menu – the new Visual Studio Git experience! (Maybe Microsoft acquiring GitHub wasn’t all that bad?!)
Whilst I aim do most of my git activity via the CLI due to personal preference – there’s no way I can justify the use of Vim to take care of my merge conflicts in 2021. So I used to use the free and lightweight tool Meld; a tried-and-trusted method for me for the past 5 years.
But whilst working through conflict-hell of late, I was examining my conflicts line-by-line in Meld when I suddenly lost patience and decided to have a look around at my options, and that’s when I stumbled on this nice little doohickey!
Below are the steps to get it up and running after you’ve updated to the latest version of Visual Studio 2019.
1. Configure Visual Studio Merge Editor
First of all we need tell Git that you’re planning to use Visual Studio Merge Editor going forward.
Open up the Git context menu, and go to Settings.
In the Options pane under Merge tool, click Use Visual Studio:
2. Get used to the new terminology
Perhaps a good pub quiz question would be: What’s the difference between LOCAL, REMOTE, BASE and MERGED files? The answer of course depends on the context – but Visual Studio’s new tool does away with this confusing terminology and replaces it with Incoming, Current and Result:
3. Keep your conflict reviews relevant
What I particularly like about this tool is the nice little button along the top here – Show Conflicts Only
Users of Meld, KDiff3 or similar merge tools won’t be used to this option! If a merge has been successful in another part of the file, why should this ever be brought to my attention during a conflict editing operation?
Minor Annoyance
Upon successfully completing a merge operation in git, when you go to commit your changes git will generally populate your commit message for you – something along the lines of;
Merge tag '5.0.9.967' of https://github.com/xxx into feature/foobar-123
This is a pretty useful commit message. However for some reason, Microsoft decided to override this behavoiur and omit it, so you need to provide a commit message yourself.
Tips for avoid “Conflict-hell” in the first place
- Use a concrete branching strategy – gitflow being the clear winner – and make use of your Continuous Integration tools to enforce it.
- Don’t let your active branches fall behind – do a bit of house keeping and keep those old dead branches away!