This is a very popular question on Stack Overflow.

The good news is that the fix is easy.

Setup

Let’s start from an empty repository.

A typical workflow involves editing a file, making a few changes, and then committing it once satisfied with the result.

This results in a commit tree like the following, where your last commit b06569 is the HEAD of the main branch:

alina

Since those are valid commits, we can push them to our remote repository.

At this stage, let’s make another change to the README.md file and commit it.

Now your local commit has a new HEAD b5dea6 and the commit tree looks like this:

alina

However, you realize that you made a mistake and no longer want that last commit b5dea6.

solution #1 : git reset —hard

The common solution is to use git reset --hard, but be cautious as it is also the riskiest option: any uncommitted changes will be lost.

Any committed change, even if reset by the command, can be retrieved from the reflog.

The git reset --hard command acts like a time machine, bringing you back to a previous state of your repository and removing all the changes made since a given commit.

The syntax is git reset --hard <commit>. In this case, we want to remove the last commit, so we’ll use git reset --hard HEAD~1.

As indicated by the command, the HEAD is now at commit b06569b:

alina

In the graph above, we can still see the commit b5dea6, but it no longer has a reference pointing to it. It will be garbage collected.

The git reflog command shows that if you change your mind, you can always retrieve that commit if you act before garbage collection occurs.

The git status command shows that the working tree is clean and the index is empty.

solution #2 : git reset [—mixed]

Let’s first recreate an unwanted commit.

Now we’re back to a commit graph like this:

alina

Let’s undo that last commit 9c27cc3 using the git reset command.

If no mode is specified for the git reset command, it defaults to --mixed.

This leads to a commit tree like the following:

alina

The difference with git reset --hard is that the working tree is not cleaned up: the (unwanted) changes are still present, but they are no longer staged.

With git reset --mixed, we are still back in time, but only up to the point where the file was modified, not yet staged.

Let’s stage and commit that file again, so that we can explore the third way to use git reset.

This results in a commit tree like this:

alina

solution #3 : git reset —soft

Now let’s try the last mode of the git reset command: git reset --soft.

As mentioned before, the git reset command requires a reference to a commit. You can use the HEAD^n notation to refer to a commit n commits before the current HEAD, but you can also use the hash of the commit you want to reset to.

This leads to a commit tree like the following, with HEAD back at the commit b06569b.

alina

This time, the git status shows us that the working tree is clean and the index is not empty.

With git reset --soft, we are still back in time, but only up to the point where the changes were staged but before the commit was made.

As indicated by the output of the git status command, you can run git restore --staged README.md to unstage the changes.

That will bring you back to the state where the working tree is clean and the index is empty.