PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To undo your latest commit and keep its changes staged, run git reset --soft HEAD~1. To keep the same changes in your files but unstaged, run git reset HEAD~1. Neither command deletes your edits. Use them only on a commit that no one else has pulled. If the commit is already shared, run git revert HEAD instead.
Check the commit before you reset
Confirm three things first, because each reset rewrites the current branch tip:
- Which commit is at the tip. Run
git log --oneline -3. The commit you want to undo should be the top line. - Whether anyone else has it. Run
git log --oneline @{u}..HEAD. This lists local commits that have not been pushed to the upstream branch. If your commit appears there, it has not been shared through that remote. If it does not appear, it has already been pushed, and you should follow the revert path below. - What uncommitted work you have. Run
git status. Staged, unstaged, and untracked files all behave differently during a reset, so know what is there before you change anything.
Keep the changes staged: --soft
Run this when you want the commit gone but its changes still ready to commit again:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
git reset --soft HEAD~1
The branch tip moves back one commit. The index (the staging area) and the working tree are left unchanged, so the files keep their edits and git status shows those edits as staged. This is the usual choice when you want to fix a commit message, split the work into different commits, or add a file you forgot.
#1 Best Overall
Keep the changes unstaged: the default --mixed mode
Run this when you want the commit removed and the changes back in your files, but not staged:
git reset HEAD~1
Git moves the branch tip back and resets the index to match the new tip. The working tree is not touched, so your edits remain in the files. The difference from --soft is only the staging state. Use this mode when you want to review each file again before choosing what to stage.
Rank #2
- Used Book in Good Condition
Why --hard is not a preservation command
git reset --hard HEAD~1 resets both the index and the working tree to the target commit. Edits to tracked files that were not committed are overwritten. Git also warns that the command may overwrite untracked files. Do not use it when you need to keep work. Choose --soft or the default mode instead.
Compare the options
The commands differ in three ways: whether the branch history is rewritten, what happens to the index, and whether your working files are touched.
Rank #3
| Command | Effect on the branch | Index (staged changes) | Working tree files | Best use |
|---|---|---|---|---|
git reset --soft HEAD~1 |
Tip moves back one commit | Unchanged, so the commit’s changes stay staged | Unchanged | Unpushed commit you want to recommit or reshape |
git reset HEAD~1 |
Tip moves back one commit | Reset to the new tip, so changes become unstaged | Unchanged | Unpushed commit you want to restage selectively |
git reset --hard HEAD~1 |
Tip moves back one commit | Reset to the target commit | Reset to the target commit; may overwrite untracked files | Discarding work. Not for keeping changes |
git commit --amend |
Replaces the tip with a new commit | Staged changes are included in the replacement | Not reset | Correcting the latest commit or its message |
git revert HEAD |
Adds a new commit that reverses the latest commit; history is not rewritten | Requires a clean working tree | Requires a clean working tree | Undoing a commit that is already shared |
The Git reference for amend notes that rewriting a commit that has already been published can affect collaborators. That is the main reason to prefer a revert once a commit is shared, as described in the git-commit documentation.
Step-by-step: choose the right command
- Run
git statusand note any staged, unstaged, or untracked files you need to keep. - Run
git log --oneline @{u}..HEAD. If your commit is listed, it is local and can be rewritten. - If it is local and you want its changes staged, run
git reset --soft HEAD~1. - If it is local and you want its changes unstaged, run
git reset HEAD~1. - If it is already shared, skip to the revert steps below.
- Run
git statusandgit diff --stagedagain to confirm the files are where you expect before making a new commit.
When the commit is already shared: git revert HEAD
A revert does not move the branch backward. It records a new commit that applies the inverse of the latest commit, so collaborators who already have the original commit do not have to rewrite their history. The git-revert documentation describes this as reverting the changes that the related patches introduce and recording new commits for them.
Rank #4
- Make sure the working tree is clean. Revert requires it. If you have pending edits, either commit them or set them aside with
git stash push -u. - Run
git revert HEAD. Git opens an editor for the revert message. Save and close it to finish, or add--no-editto accept the default message. - Run
git log --oneline -2to confirm the new revert commit sits above the original. - If you stashed changes, restore them with
git stash pop.
If you reset by mistake
Git saves the previous branch tip to ORIG_HEAD when a reset runs. That reference can help you go back to the old commit, but it is not a guaranteed recovery method. Other Git operations can overwrite it, and it depends on the repository state at the time. Check the result with git log before you rely on it. To return the branch to the old tip while keeping the index and working tree as they are now, run git reset --soft ORIG_HEAD, then confirm with git status.
For a deeper explanation of how reset moves the branch, index, and working tree, see the Pro Git chapter on resetting. The Git project’s user manual, “Fixing mistakes”, covers other recovery scenarios.
Best Value
Versions and scope
These commands behave the same way in current Git releases. The reset reference used for this guide is version 2.53.0, published in the git-reset documentation for 2.53.0. The commands apply to any Git repository, including those hosted on GitHub, GitLab, or Bitbucket, because the reset and revert actions happen in your local clone.
The reset commands affect only the current branch. If you work on several branches, check which one is checked out with git branch --show-current before you run them.
Do not write HEAD~1 if your latest commit is a merge commit unless you have checked what that parent represents. Use git log --graph --oneline to see the history first.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
