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.
Yesterday’s tip was about making changes to your commit message. Today’s tip is making changes to your code as well.
Hey my Git experts friends reading this! I’m not sure what the command line equivalent is, so can someone look at my section below on using the CLI and tell me why I have to use –allow-empty?
We’ll start with Team Explorer in Visual Studio and then rinse and repeat with what I think is the equivalent git command.
Amend using Visual Studio
It looks like Team Explorer will let you amend based on whatever changes are in the working directory, but just in case you only want to change one file, I’d suggest staging the file(s )you want to amend first. In a command line scenario, whatever files are in staging are the ones that will be amended. (See previous tips)
Click on the Actions button and select Amend Previous Commit.
And you’ll get a new commit ID.
Amend using Command Line
Full disclosure: I don’t know when to use the –allow-empty option. I also don’t know what the ramifications of using it are. It seems I need to use this option even though 1. the staged changes are different than those in the commit history and 2. I’ve specified a commit message. TBH I’m not sure what is going on here.
But this is my best guess at the command line equivalent of what Team Explorer is doing.
- make changes to your file
- use git add to add those changes to staging
- git commit –amend -m “new message” –allow-empty or git commit –amend –allow-empty (but I’m not sure)
The below screenshot shows what happens when I don’t use the –allow-empty option.
and here’s what happens when I use the –allow-empty, which turns out to be the behavior I want (or as far as I know!)
So yeah, if you know what is going on wrt to the –allow-empty option, please let me know!!