Suppose this time you have conflicts when you do a Pull, meaning your local branch had a conflicting change that was committed locally (but not yet pushed – see Outgoing Commits 1 in screenshot below) and someone else (let’s say you via GitHub.com UI) made a corresponding  conflicting change on the remote.

Here’s the UI setup in Team Explorer. Click on Pull.

Git halts the pull operation (at the merge portion) when it detects the conflicting changes, as expected.

From here it should be familiar territory by now. Clicking conflicts brings you to a merge conflict screen.

Clicking Merge brings up the 3 way merge tool (or choose a take remote  or a keep local). If you go the Merge tool route, make sure you click “Accept Merge” at the top. Gets me every time.

Once you’ve accepted the merge (or choose to use the remote or local version), click Commit Merge.

 

Now we have to commit those our resulting merge. Click Commit Staged in Changes pane in Team Explorer.

and you’re done! Reviewing the local master history shows the merge commit now as the tip.

Still thinking re yesterday how a Pull is different than a Fetch + Merge. I guess if you know you want to download changes, but not ready to deal with any potential conflicts at this time (e.g. going offline for a while or got other things to do right now), Fetch is the way to go. If you know you’re ready to start playing with the code on your local branch, then Pull is the way to go, I think.

• Git(Hub) Tip of the Day 2017