If you git revert the last commit, you're doing version control wrong. Use git reset --hard instead. It's the choice that makes sense in most scenarios.
Don't git revert the last commit
If you do feel the need to git revert the last commit, my first question would simply be, "Why?" Was there something in the previous commit you didn't like? Did your source code go in the wrong direction and you simply want to start over? If that's the case, a git revert is the wrong thing to do. You need to do a git reset, not a revert.
Here's why it's better to reset, not revert to the last commit. First, when you git reset the last commit, the ID of the bad commit isn't pushed to any remote repository. With a reset, there won't be record of the bad commit on GitHub or Bitbucket. Your local reflog will still track it so it's locally recoverable, but there will be no record of the commit in the team repository.
Git reset previous commits
The other nice thing that happens when you git reset the last commit is that no new commits are created. The HEAD pointer simply moves back a slot and when you look at the branch history, it's as though the bad commit never happened.
Contrast that against git revert. When you git revert the last commit, not only does the full commit history remain intact, but a new commit is created. When you git revert the last commit and push your changes to a shared repository such as GitHub, fellow developers will see three separate commits -- all with unique commit IDs. And to further confuse matters, the first and the third commits will be exactly the same in terms of content. Only the second commit will contain the mistakes. When you git revert the last commit, you complicate the commit history. The reset command eliminates this confusion.
When you git revert the last commit, it stays in your history and even gets pushed to a remote repository like GitHub or GitLab.
Git reset --hard vs. --soft
There are other benefits to be reaped when you git reset the last commit. With this method, you can specify either a hard or soft option. When you git reset --hard the last commit, not only does the head move back, but the state of all of the files in your working directory are reset as well. The git reset --hard option would provide the same workspace and index behavior you would see when you git revert the last commit, without all of the associated complications.
However, if you git reset --soft, the head will move back to a point at a prior commit, but none of the files in the working directory will change. That means you don't have to scrap all of your changes, and can pick up from where you left off without the last commit you were unhappy with hanging around like a bad odor.
How to properly undo the last git commit
If you want to reset your workspace and dispose of the last commit, use the git reset command.
Trying to undo a mistake with a git revert on the last commit is simply the wrong approach. Because the names sound similar, many people confuse and conflate the Git revert and reset commands. The git revert command is intended to pull the isolated changes made within a previous commit -- with surgical precision -- out of the current code base. A popular tutorial on TheServerSide demonstrates exactly how it works when you git reset a commit, and the behavior of the command is not what people expect.
The git reset --hard command is much easier to understand because it does exactly what people expect it to do -- it resets everything back to the way it was in a prior commit.
If you want to reset your workspace and dispose of the last commit, use the git reset command. Trying to git revert the last commit is typically the wrong approach.
