git reset: soft, mixed, hard

Why this matters

git reset is the command most often copied from the internet without understanding, and --hard is the flag most often copied along with it. The three modes differ in exactly one way, and once you see it, the command stops being frightening.

What all three have in common

Every mode moves the branch pointer to the commit you name. That part never varies. What varies is what happens to the change that was in the commit you just moved past.

The same repository, three times

Each example below starts from an identical repository: one commit on top of d3b92ec, adding a Windows section to the installation guide, with a clean working tree.

--soft

$ git reset --soft HEAD~1
$ git status --short

M  docs/getting-started.md

$ git log --oneline -1

d3b92ec chore: add CI configuration and contributing guide

The commit is gone from the branch and its change is staged, ready to be committed again. The M is in the left column, which is the staging column (lesson 5.1).

Use it when the change was right and the commit was not: a bad message, a commit that should be two, a file you forgot.

--mixed, the default

$ git reset --mixed HEAD~1

Unstaged changes after reset:
M	docs/getting-started.md

$ git status --short

 M docs/getting-started.md

The commit is gone and the change is in your files but not staged. The M moved to the right column. This is what plain git reset HEAD~1 does, since --mixed is the default.

Use it when you want to rebuild the commit from scratch, staging pieces deliberately.

--hard

$ git reset --hard HEAD~1

HEAD is now at d3b92ec chore: add CI configuration and contributing guide

$ git status --short

Nothing. The working tree is clean and the Windows section is gone from the file:

$ tail -3 docs/getting-started.md

- Read the [FAQ](faq.md).
- Read [CONTRIBUTING](../CONTRIBUTING.md) before making changes.

The commit itself is still findable in the reflog, so the committed work is recoverable. Anything that was uncommitted when you ran it is not.

Which to use

Naming the target

Reset takes any commit reference:

git reset --hard origin/main is worth knowing as the "start again from the server" command. It is also the one that has destroyed the most unfinished work, because it discards everything local without asking.

The safety habit

Three seconds of typing prevents the only irreversible outcome:

1. git status — is anything uncommitted? If yes, --hard will destroy it.
2. git stash -u if there is something to keep.
3. git log --oneline -3 — confirm you are aiming at the commit you think you are.
4. Then reset.

How to do it

$ git reset --soft HEAD~1     # keep everything staged
$ git reset HEAD~1            # keep changes in the files, unstaged
$ git reset --hard HEAD~1     # discard the changes too

Common mistakes

• --hard with uncommitted work open, which is the one unrecoverable outcome here.
• Using reset on a pushed branch, which needs a force push to publish (lesson 12.8).
• Confusing git reset <file> with git reset --hard. The first unstages a file; the second rewrites everything.
• Counting HEAD~n wrongly. Check with git log --oneline first; a hash is safer than a count.
• Reaching for reset when git revert is the correct answer.