Git Reset: Hard, Soft and Mixed Explained

git reset is one of those commands where the options have dramatically different consequences and the documentation is just dense enough to send people to Stack Overflow every time. I've taught Git to dozens of developers and 'git reset --hard and I lost my work' is in the top three support requests, every time.

The mental model that prevents mistakes: think of git reset as moving a bookmark in a book. The three modes control whether you keep the pages you're jumping over.

The Three Modes: Hard, Soft, Mixed

All three modes move HEAD (and the current branch pointer) to the specified commit. The difference is entirely in what happens to the working directory and the staging index.

--soft: HEAD moves back. Working directory untouched. Staging index untouched. The changes from the undone commits are staged and ready to recommit. Use this for 'I committed too early' or 'I want to rewrite the last N commits into one'.

--mixed (default): HEAD moves back. Working directory untouched. Staging index cleared. Changes appear as unstaged modifications. Use this for 'I committed the wrong things' or 'I need to regroup and re-add selectively'.

--hard: HEAD moves back. Working directory changed to match the target commit. Staging index cleared. Any uncommitted changes are gone. Use this when you genuinely want to throw away work. This is the only mode that can lose data.

# Current state: 3 commits ahead of where we want to be
git log --oneline
# d4f8b3c (HEAD) Add unit tests
# 9c3e8a2 Fix null check
# 7b2d4f1 Add backoff logic
# a3f9c2e (origin/main) Initial PaymentRetryService

# --soft: undo commits, keep changes STAGED
git reset --soft HEAD~3
git status
# Changes to be committed: all 3 commits' changes are staged
# Use case: squash 3 commits into 1 clean commit

# --mixed (default): undo commits, keep changes UNSTAGED
git reset HEAD~3
# or: git reset --mixed HEAD~3
git status
# Changes not staged for commit: all 3 commits' changes in working dir
# Use case: regroup changes before re-adding selectively

# --hard: undo commits, DISCARD changes entirely
git reset --hard HEAD~3
git status
# nothing to commit, working tree clean
# WARNING: the changes from those 3 commits are gone

# Reset to a specific commit hash
git reset --soft a3f9c2e
git reset --hard a3f9c2e

# Reset a single file (unstage it)
git reset HEAD -- src/main/java/io/thecodeforge/payment/PaymentService.java

git reset vs git revert: Which to Use

This is the question that trips up the most people in interviews and in practice. The key distinction: reset rewrites history, revert adds to history.

git reset moves the branch pointer backward. The commits you reset past effectively disappear from the branch. This is fine on your local feature branch. On a shared branch, it rewrites public history and requires a force push — which breaks teammates' local copies.

git revert <hash> creates a new commit that undoes the changes of the specified commit. History is preserved. The original commit is still there. You push normally. This is what you use on main, develop, or any shared branch.

Rule of thumb: reset for local cleanup on your own branches. Revert for undoing things on shared branches.

# RESET: rewrites history (local branches only)
git reset --hard HEAD~1    # Undo last commit, discard changes
git reset --soft HEAD~1    # Undo last commit, keep changes staged
# If already pushed: requires force push — DON'T do on shared branches
git push origin feature/my-branch --force-with-lease

# REVERT: adds a new 'undo' commit (safe for shared branches)
git revert HEAD            # Undo last commit
git revert a3f9c2e        # Undo specific commit
git revert HEAD~3..HEAD   # Undo last 3 commits (creates 3 revert commits)
git revert HEAD~3..HEAD --no-commit  # Stage all reverts, commit once
git push origin main      # Normal push — history intact

Frequently Asked Questions