Git undo cheat sheet: restore, reset, revert and reflog

Almost every Git mistake can be undone, as long as you pick the right command and know whether the work was ever committed or pushed. The trouble is that Git offers five ways to "go back", and the wrong one can throw away uncommitted work for good.

This Git undo cheat sheet groups commands by situation. It explains git restore vs reset vs revert, how to handle git undo local changes safely, fixing the last commit, recovering lost commits with reflog, parking work with stash and force-pushing with --force-with-lease on shared branches.

This cheat sheet groups the undo commands by situation, from discarding an edit to rescuing a deleted branch, and marks which ones are safe on shared branches. Every command was run in a practice repository with Git 2.54 on 9 October 2026 (Git 2.56.0 is the newest release listed on git-scm.com), and the behaviour notes come from the official Git documentation and the Pro Git book.

The short answer: git restore discards or unstages changes to files; git reset moves your branch back and rewrites history, so use it only before pushing; and git revert adds a new commit that undoes an old one, which is safe on shared branches.

Pick the right command in ten seconds

The rule behind the third column comes straight from Pro Git: only amend commits that are still local, because amending previously pushed commits and force-pushing "will cause problems for your collaborators". The same applies to reset on any commit others may have pulled.

Undo changes you have not committed

Discard edits in the working tree

git restore app.txt          # one file
git restore .                # everything under the current directory

Pro Git is blunt about this one: git restore <file> is "a dangerous command", because any local changes to the file are gone. Committed work can nearly always be recovered; work that was never committed usually cannot. If in doubt, stash instead.

Unstage without losing anything

git restore --staged app.txt # was: git reset HEAD app.txt

git restore and git switch arrived in Git 2.23 to split the many jobs of git checkout into clearer commands. git status prints these hints for you, so read its output before reaching for a command from memory.

Remove untracked files carefully

git clean -n     # dry run: lists what would be deleted
git clean -f     # actually delete untracked files
git clean -fd    # ...and untracked directories

Always run -n first. In our practice repository it printed Would remove tmp.log and touched nothing.

Fix the last commit

git commit --amend -m "Better message"   # change the message
git add forgotten.txt
git commit --amend --no-edit              # add a file, keep the message

Amending replaces the commit with a new one; as Pro Git puts it, it is as if the previous commit never happened. Fine on a local branch, a problem on a shared one.

Undo commits: reset versus revert

git reset moves the branch pointer

git reset --soft HEAD~1 is the cleanest way to "uncommit" and recommit differently, for example to split a commit in two. Use --hard only after checking git status; the commits it removes can be recovered through the reflog, but uncommitted edits cannot.

git revert adds an opposite commit

git revert a1b2c3d                 # opens an editor for the message
git revert --no-edit a1b2c3d       # use the default "Revert ..." message
git revert -m 1 <merge-commit>     # revert a merge, keeping parent 1 as mainline

The Git documentation describes revert as recording new commits that reverse the effect of earlier ones, which is why it is the right tool on main or any branch others use. Reverting a merge needs -m to say which parent is the mainline, and the documentation warns that it declares you will never want that merge's changes: merging the same branch again later will not bring them back unless you revert the revert.

Rescue work you thought was lost

The reflog: Git's undo history

The reflog records when the tips of branches and other references were updated in your local repository, including every commit, reset, rebase and branch switch. Entries are kept for 90 days by default (gc.reflogExpire), or 30 days for entries no longer reachable from the branch (gc.reflogExpireUnreachable). It exists only on your machine; a fresh clone has none of it.

git reflog -5
# 73de51a HEAD@{0}: reset: moving to HEAD~2
# 3d2ff30 HEAD@{1}: commit: third again
# ...

git reset --hard 'HEAD@{1}'   # put the branch back where it was before the reset

This is the exact sequence we ran: after a git reset --hard HEAD~2 removed two commits, git reset --hard 'HEAD@{1}' brought both back. Quote HEAD@{1} so shells such as zsh do not interpret the braces.

Restore a deleted branch

git branch -D experiment
# Deleted branch experiment (was 20e41f8).

git branch experiment 20e41f8     # recreate it from the printed hash
# or find the hash later with: git reflog | grep experiment

Get one file from the past

git restore --source=HEAD~2 app.txt     # working tree only
git log --oneline -- app.txt            # find the commit you want first

To find the commit that added or removed a piece of text, git log -S "text" --oneline searches the history of changes rather than commit messages.

Park work and switch context

git stash push -u -m "wip: pricing page"   # -u includes untracked files
git stash list
git stash pop                              # re-apply and drop the stash
git stash apply stash@{1}                  # re-apply, keep the stash

For longer interruptions, such as an urgent fix while a feature is half done, a worktree is often better than a stash. It checks out a second branch in a separate folder that shares the same repository:

git worktree add ../myapp-hotfix -b hotfix
# fix, commit and push from ../myapp-hotfix, then:
git worktree remove ../myapp-hotfix

Force-pushing safely

If you rewrote your own feature branch with amend, reset or rebase, the remote will reject a normal push. Use --force-with-lease rather than --force: the git-push documentation explains that it refuses the update unless the remote branch still points where your remote-tracking branch says it does, so you cannot silently overwrite a colleague's new commits.

git push --force-with-lease --force-if-includes origin feature/login

The documentation adds a caveat: if something runs git fetch in the background, such as an editor, the lease check can pass without you ever having seen the new commits. --force-if-includes closes that gap by also checking that the remote tip appears in your local reflog. You can make it the default with git config --global push.useForceIfIncludes true. Never force-push to main; protect it on GitHub or GitLab so nobody can.

How to choose, in one paragraph

Ask two questions. Was it committed? If not, restore and stash are your tools, and anything you discard is gone. Was it pushed to a shared branch? If yes, use revert; if no, amend and reset are fine. And whenever something seems lost, run git reflog before you panic.

Practise before you need it

Create a throwaway repository, make three commits and try each command in this guide. Five minutes of practice is much cheaper than learning reset modes during an incident. For the commit that broke your build, pair this sheet with git bisect; for the full reference, the free Pro Git book and the Git reference manual are maintained on git-scm.com.