Undo Most Recent Local Git Commits: Reset Guide

Use git reset to move HEAD back and undo the most recent local commits—choose --soft, --mixed (default) or --hard depending on whether you want to keep staged or working-tree changes. If you need to avoid rewriting history (or the commit was already shared), use git revert to create a new commit that undoes the changes. Since you haven’t pushed yet, the fastest fixes are git reset --soft HEAD~1 (keeps changes staged) or git reset HEAD~1 (keeps them unstaged).

Contents

• Quick commands: undo last commit (copy-paste)
• How git reset works (soft / mixed / hard)
• When to use git reset vs git revert
• Fix a commit that added wrong files — step‑by‑step
• Recovering after a bad reset (reflog & restore)
• Sources
• Conclusion

Quick commands: undo last commit (copy-paste)

Use these quick commands depending on what you want to keep or discard.

• Undo last commit but keep changes staged (ready to re-commit):

git reset --soft HEAD~1

• Undo last commit but keep changes unstaged (you can edit and selectively stage):

git reset HEAD~1
# same as: git reset --mixed HEAD~1

• Undo last commit and discard all changes from that commit (destructive):

git reset --hard HEAD~1

• Create a new commit that undoes the last commit (safe for shared branches):

git revert HEAD
# skip the editor:
git revert --no-edit HEAD

• Undo multiple commits (N commits back):

git reset --soft HEAD~N
# or to a specific commit:
git reset --hard <commit-sha>

• If you only want to remove a file from the last commit and keep it locally:

git reset --soft HEAD~1
git restore --staged path/to/file # (or: git reset HEAD path/to/file)
git commit -m "Commit without that file"
# OR remove from index permanently:
git rm --cached path/to/file
git commit --amend --no-edit

Want authoritative detail on modes? See the official git-reset documentation: https://git-scm.com/docs/git-reset.

How git reset works (soft / mixed / hard)

Briefly, git reset moves the branch pointer (HEAD) to an earlier commit and optionally updates the index and working tree:

• --soft: moves HEAD only. The index (staging area) and working tree are left as-is. The undone commit’s changes remain staged. Good when you want to rework the commit message or adjust staged files before recommitting.
• --mixed (the default): moves HEAD and resets the index to the target commit, but leaves your working tree alone. Changes are unstaged so you can selectively stage them again.
• --hard: moves HEAD, resets the index, and resets the working tree to match the target commit. Local changes are lost. Use with caution.

Why the different modes? Because sometimes you only want to “uncommit” (keep work), sometimes you want to “uncommit and unstage” (edit before re-commit), and sometimes you truly want to throw away the work.

Heads-up: git reset rewrites history for the branch. That’s fine for local commits that haven’t been pushed. If you reset a commit that others already pulled, you’ll create trouble for collaborators.

For more technical notes and examples, check the official docs: https://git-scm.com/docs/git-reset.

When to use git reset vs git revert

Which should you use — reset or revert?

• Use git reset when the commit is local (hasn’t been pushed) and you want to rewrite history (remove or squash commits). It’s quick and flexible. Example: you accidentally committed debug files and want to re-commit without them.
• Use git revert when the commit has been pushed or shared. git revert <sha> creates a new commit that undoes the changes without altering history. Safe. No force-push needed.

So: you haven’t pushed yet — reset is usually the right tool. If you later do rewrite history and need to update the remote, prefer git push --force-with-lease and coordinate with your team (but that’s only if you must rewrite pushed history).

If your goal was only to tweak the last commit (message or include missing files), git commit --amend is often simpler:

# add or remove files as needed, then:
git commit --amend

This replaces the last commit with a new one (again, don’t do this after pushing unless you know what you’re doing).

Further reading / friendly walkthrough: https://www.git-tower.com/learn/git/faq/undo-last-commit

Fix a commit that added wrong files — step‑by‑step

Scenario: you accidentally committed the wrong files (e.g., temp files, large binaries, or sensitive info), and you haven’t pushed.

1. Inspect what you committed

git status
git log --oneline -n 5
git show --name-only HEAD

2a. If you want to uncommit but keep changes staged (fastest):

git reset --soft HEAD~1
# now everything from the last commit is staged
# unstage unwanted files:
git restore --staged path/to/bad.file # (or: git reset HEAD path/to/bad.file)
# optionally remove file from index permanently:
git rm --cached path/to/bad.file
# then re-commit correct set:
git commit -m "Fix: commit without bad file"

2b. If you want the changes unstaged so you can pick what to commit:

git reset HEAD~1 # (mixed reset)
# edit files, then:
git add good-files
git commit -m "Commit only good files"

2c. Amend the last commit (useful when you just forgot to include/exclude something):

# remove the unwanted file from index but keep it locally:
git rm --cached path/to/bad.file
# then amend:
git commit --amend --no-edit

3. Prevent the file from being re-added:

• Add it to .gitignore if it should never be tracked.
• If the file must be removed from history entirely (and it was pushed), you’ll need history-rewrite tools like git filter-repo or BFG (this is more advanced and requires care).

Quick tips:

• If you have uncommitted work you want to keep around while experimenting, stash it: git stash push -m "WIP".
• After fixing, verify history: git log --oneline --graph -n 5.

Need a localized walkthrough? This guide shows practical examples: https://timeweb.cloud/tutorials/git/kak-otmenit-izmeneniya-v-git and community discussion: https://ru.hexlet.io/qna/git/questions/kak-otmenit-posledniy-kommit-git.

Recovering after a bad reset (reflog & restore)

Accidentally ran git reset --hard and lost a commit? Don’t panic right away.

• git reflog records where HEAD pointed recently. It’s your first stop:

git reflog
# find the SHA for the HEAD you want to restore (e.g., abc123)
git reset --hard abc123

• ORIG_HEAD is sometimes set by dangerous commands (like git reset) and may point to the previous tip:

git reset --hard ORIG_HEAD

Reflog and these commands can usually recover commits until Git’s garbage collector prunes unreachable objects. So act quickly. For practical examples of recovery and when to use reflog, see this helpful Q&A: https://stackoverflow.com/questions/927358/how-do-i-undo-the-most-recent-local-commits-in-git

Sources

• How do I undo the most recent local commits in Git? - Stack Overflow
• How can I undo the last commit? - Git Tower
• Git - git-reset Documentation
• How to undo the last commit in Git - Hexlet Q&A (RU)
• How to undo changes in Git: git reset, revert, checkout - Timeweb

Conclusion

To undo the most recent local commits in Git you typically use git reset (for unpushed commits) with --soft to keep changes staged, --mixed to keep them unstaged, or --hard to discard them. If you must preserve history or the commit is already shared, use git revert instead. Always inspect the commit with git log/git show first, and remember git reflog can often help recover a reset gone wrong.