Git Reset: Undo Commits With --soft and --hard

If you’ve ever made a commit and immediately thought “noooope”, then git reset is what you need. It’s one of the most useful Git commands for undoing work, but it’s also one of the easiest to misuse. The --soft version is usually safe and predictable. The --hard version is powerful and can absolutely nuke your local changes.

All the content from our Boot.dev courses are available for free here on the blog. This one is the “Reset” chapter of Learn Git. If you want to try the far more immersive version of the course, do check it out!

What Does Git Reset Actually Change?

git reset can affect three things:

1. HEAD (what commit your branch points to)
2. The index (your staged changes)
3. The working tree (your files on disk)

Different flags change different layers.

If you want broader branch-history context first, start with Git Branching and Git Rebase.

How Do You Undo a Commit but Keep Your Changes?

Use the --soft flag.

git reset --soft COMMITISH

This moves your branch pointer back to COMMITISH (which can be a commit hash, branch tip, tag, etc), but your reverted commit’s file changes stay staged.

That’s perfect when your last commit message is bad, or you want to squash/rework the commit before pushing. The typical flow is:

git log --oneline
git reset --soft <target-commit>
git status

After the reset, git log no longer shows the removed commit, and git status shows those changes as staged and ready to recommit.

What Does Git Reset --hard Do?

The --hard flag is much more heavy-handed:

git reset --hard COMMITISH

It resets all three layers (HEAD, index, and working tree) to the target commit. If local changes are only in your working tree or staging area, they’re gone.

This is useful when your branch is a mess and you intentionally want a clean rollback.

It’s not useful when you might want your work back later.

Why Is Git Reset --hard Considered Dangerous?

Because it can permanently discard local changes.

If a file change was never committed anywhere, and you wipe it with --hard, Git usually can’t help you recover it.

[!warning] git reset --hard is fast, clean, and brutal. Run it only when you are certain you don’t need the discarded work.

When in doubt, make a backup branch first:

git switch -c backup-before-reset

Then go do destructive stuff on the original branch.

When Should You Use --soft vs --hard?

Use --soft when you want to rewrite recent commits but keep the code changes.

Use --hard when you want your branch and files to exactly match an older commit and you intentionally want to discard local work.

• If your goal is to combine branch histories without merge commits, that’s not reset territory — use Git Rebase.
• If your goal is to combine completed branch work, use Git Merge.
• If your goal is to create a new commit that is the inverse of a previous commit use git revert.

How Do You Reset to a Specific Commit?

Find the target hash in git log, then reset to it:

git log --oneline
git reset --hard a1b2c3d

You can use full hashes or short hashes as long as the short one is unambiguous.

If you’re working solo on your feature branch, this is usually straightforward. If you’re rewriting commits that teammates already pulled, coordinate first.

If you want to learn about advanced undo workflows (including options after mistakes), our Learn Git 2 course goes even deeper.