Git Reset: Use With Caution

Today I was working through a well-designed git tutorial, part of a larger exercise-based curriculum. (I won’t say which company wrote this tutorial, because their content is excellent in general!)

This tutorial introduced the git reset command as the correct way to revert to an earlier commit. For instance, you’ve been working on some changes and you don’t like them, so you want to go back to an earlier commit. Or, you check the remote repo, you see that someone else has pushed some changes, but you are two commits ahead. You decide to go back to the last commit on the remote repo, so you run git reset commit-hash-here.

Frankly, git reset kind of gives me the willies.

As this great article or this great Stackoverflow post explains, `git reset` will do one of three things.

• git reset --soft will undo your last commit, and make your HEAD (which tracks your latest commit) look like your staging area.
• git reset --mixed will do the above, and then go on to undo your latest additions to your staging area.
• git reset --hard will do both of the previous two steps, and then also erase your latest file changes and go back to the last commit.
• git reset --any-flag commit-hash-here does everything above, but you specify exactly which commit we’re going back to.

As you can see, reset is about destroying changes you don’t like. But wait a minute: git means never having to say you’re sorry!

If you’re not working on master, and hopefully you’re not because you always create a new branch and then switch to it because you’re an awesome programmer, then it’s easy to leave out any changes you don’t like. No need to destroy things!

At the very least, I’d teach git checkout commit-hash-here first, and git reset later. git checkout should be our bread and butter, so that we can take full advantage of the magic of git.