Today’s tip shows how to combine doing a Fetch and a Merge by using the Pull command.
Suppose you have some incoming commits that you’re ready to merge into your local branch. In this example, I’ve create a new file on master on GitHub and I want to bring that commit into my local master branch.
Instead of fetching to review the commits that are going to be applied, we’ll assume you’ve already looked at GitHub to see what will be merged in.
The result of the Pull command shows a message at the top of the Team Explorer.
Viewing the history on the master branch shows the tip (the top of the branch) having the newly merged in commit from GitHub.
This begs the question: Why use Fetch? Why not always do a Pull? I believe the answer is
- if you want to verify what commits have been downloaded
- if you want to know if you’ll run into any merge conflicts before doing the Pull (the merge portion of Pull). However, I’m not sure how you can know if you’re going to have any merge conflicts, if you haven’t first merged the commits somewhere. I guess you could manually review the changes. Perhaps someone reading this knows what I’m missing.