Quick answer
Undo a commit with `git reset` if the change has not yet been pushed to the remote repository, or with `git revert` if it has already been shared with others. Before anything, check `git status` and `git log`, because `git reset --hard` permanently deletes uncommitted changes in tracked files.
How to recognize the problem
- You made a commit with the wrong files or message
- The last commit broke the build or tests
- The commit has already been pushed to the remote repository so you don't know how to remove it
- You accidentally ran `git reset --hard` and lost changes
- The working tree is in a strange state after a failed reset
Most common causes
Wrong commit content
Files that should not be there ended up in the commit, such as a `.env` file or changes from another branch.
Commit with a code error
The change passed locally but breaks tests or the application, so the previous version needs to be restored.
Commit already shared
If the commit was pushed to the `main` branch that others use, rewriting history causes problems for collaborators.
Misunderstanding reset options
`--soft`, `--mixed` and `--hard` treat the index and working directory differently, so changes are easily lost.
Step-by-step fix
- 1
Check the current repository state
Run
git statusto see if there are uncommitted changes andgit log --oneline -5to see the last five commits. Write down the hash of the commit you want to return to, because you will need it in the following steps. If there is uncommitted work, save it first withgit stash. - 2
Save a backup branch
Before any reset, create a branch that points to the current state:
git branch backup-<name>. That way you can return to the old state if something goes wrong. This branch does not interfere and you can delete it later withgit branch -D backup-<name>. - 3
Undo the last commit without deleting changes
If you want the commit to disappear but the changes to remain in the working directory, use
git reset --soft HEAD~1. The files remain modified and ready for a new, correct commit. This is the safest option for local work. - 4
Restore the index and working directory to the previous commit
To fully restore the previous state, use
git reset --hard HEAD~1. Warning: this command removes the last commit from the current branch and permanently deletes all uncommitted changes in tracked files. First checkgit statusand create a backup branch. - 5
Return to a specific commit by hash
If you are not reverting only the last commit, specify the hash:
git reset --hard <hash>. Find the hash ingit log --oneline. For multiple commits back, useHEAD~3instead of the hash. The same warning applies here: first create a backup branch and checkgit status, because this command deletes uncommitted changes in tracked files. - 6
Undo a commit that has already been pushed
If the commit is already on the remote repository, do not use
reseton a shared branch. Instead rungit revert <hash>, which creates a new commit with the opposite changes. Then push withgit push. - 7
Recover lost commits from reflog
If you accidentally ran
reset --hardand lost a commit, rungit reflogand find the hash of the state before the reset. Then return withgit reset --hard <hash>, but first checkgit statusbecause this command also deletes uncommitted changes in tracked files. Reflog keeps the history of the HEAD pointer usually for 30 to 90 days, but it cannot restore uncommitted changes. - 8
Verify the result and continue working
Run
git statusandgit log --oneline -3to confirm the state is correct. If you usedrevert, check that the new commit is present. Only when you are sure, delete the backup branch.
When reset is not enough
If the wrong commit has already gone to a shared branch and others have pulled it, git revert is the safest path. Force pushing rewritten history with git push --force on a shared branch can delete other people's commits and cause conflicts for all collaborators. If you must force push, notify the team first and use --force-with-lease instead of --force, because that command stops if someone has pushed changes in the meantime. For large files or secret keys that have entered history, reset is not enough: history cleanup and key rotation are required.
How to prevent it
- Commit often and in small units, with a clear message
- Before `reset --hard` always check `git status` and create a backup branch
- Use `git revert` on shared branches, and `reset` only locally
- Regularly push work to the remote repository so it does not depend only on the local state
When to call a professional
If the wrong commit is already on a shared branch used by multiple people, or if you are not sure what reset will do to your uncommitted work, it is better to consult IT support before proceeding on your own.
Software and product development · Custom apps, SaaS and an MVP in 4 to 8 weeksFAQ
What is the difference between git reset and git revert?
`git reset` moves the branch pointer and rewrites history, so it is safe only locally. `git revert` creates a new commit that undoes the previous one and does not change history, so it is safe for shared branches.
Can I restore a commit I accidentally deleted?
You can, if you find it in `git reflog`. Run `git reflog`, find the hash of the desired state and return with `git reset --hard <hash>`.
What do --soft, --mixed and --hard mean in git reset?
`--soft` keeps changes in the index and working directory, `--mixed` (default) keeps changes only in the working directory, and `--hard` deletes changes in tracked files and returns them to the commit state.