Undo changes with restore, reset and amend

Of the five modes of git reset, only --hard can destroy work for good, and then only work that was never staged. Undoing in Git starts with one question: where is the change you want to undo? An edit you have not staged exists only in your files, and git restore <file> copies a saved version back over it. A staged change is in the index too, and git restore --staged <file> takes it out of the index while your edit stays. A commit has moved your branch, and git reset moves the branch back: --soft keeps the undone changes staged, --mixed, the default, keeps them in your files, and --hard throws them away. git commit --amend replaces only the last commit, and a commit that others already have is undone with git revert, which adds a new commit instead of rewriting their history.

Every command here runs on a small canteen repository with real Git 2.54.0: the three trees after each reset mode, four modes measured on fifteen starting states, the one loss nothing repairs, and a guide that picks the undo for your case.

git restore copies a version from one tree to another

Git keeps up to three versions of every tracked file, often called the three treesthree trees: The three versions of a tracked file that Git keeps: the working tree you edit, the index that the next commit will hold, and HEAD, the last commit. Every undo command copies a version from one of them to another.:

• the working tree: the files on disk, which you edit;
• the index, also called the staging area: the version git add recorded, which the next commit will hold;
• HEAD: the version in the last commit of the branch you are on.

git status --short prints a two-letter code per file. The first letter compares the index with HEAD and the second compares the working tree with the index: M is modified, A added, and ?? marks an untracked file. So MM means a staged change and a newer edit on top of it. Every undo command copies a version from one tree to another, and the diagram shows which:

git restore writes files and the index, never a branch, so it cannot lose a commit. This session stages one edit to the menu, dosa, makes another on top of it, poha, and then undoes them one tree at a time:

from gitsession import session

session(r"""
git --version
git init -q -b main canteen
cd canteen
printf 'idli\nvada\n' > menu.txt
git add menu.txt
git commit -q -m "Add the breakfast menu"
# Stage one edit, then make another on top of it
printf 'idli\nvada\ndosa\n' > menu.txt
git add menu.txt
printf 'idli\nvada\ndosa\npoha\n' > menu.txt
git status --short
# 1. Copy the staged version back over the file: poha goes, dosa stays
git restore menu.txt
cat menu.txt
git status --short
# 2. Copy the committed version into the index: the file keeps dosa
git restore --staged menu.txt
git status --short
cat menu.txt
# 3. Put both the index and the file back to the last commit
git add menu.txt
git restore --staged --worktree menu.txt
git status --short
cat menu.txt
""")

$ git --version
git version 2.54.0 (Apple Git-157)
$ git init -q -b main canteen
$ cd canteen
$ printf 'idli\nvada\n' > menu.txt
$ git add menu.txt
$ git commit -q -m "Add the breakfast menu"
# Stage one edit, then make another on top of it
$ printf 'idli\nvada\ndosa\n' > menu.txt
$ git add menu.txt
$ printf 'idli\nvada\ndosa\npoha\n' > menu.txt
$ git status --short
MM menu.txt
# 1. Copy the staged version back over the file: poha goes, dosa stays
$ git restore menu.txt
$ cat menu.txt
idli
vada
dosa
$ git status --short
M  menu.txt
# 2. Copy the committed version into the index: the file keeps dosa
$ git restore --staged menu.txt
$ git status --short
 M menu.txt
$ cat menu.txt
idli
vada
dosa
# 3. Put both the index and the file back to the last commit
$ git add menu.txt
$ git restore --staged --worktree menu.txt
$ git status --short
$ cat menu.txt
idli
vada

Step through the same session and watch the three versions of menu.txt, and which one each restore overwrites:

Step 1 surprises many people: git restore menu.txt did not go back to the last commit. Without --staged it copies the file from the index, so the staged dosa stayed and only the later poha went. Step 2, --staged, copied HEAD’s version into the index; the change is now unstaged ( M), but the file still lists dosa. Step 3 names both trees, and when --staged is given the source is HEAD unless --source names another commit, so the file is back to the committed idli and vada.

Two more forms are worth knowing. git restore --source=HEAD~2 menu.txt brings back the file as it was two commits ago, in the working tree only; commit it if you want to keep it. git restore . discards every unstaged edit below the current folder at once, with no confirmation and no way back for those edits, so read git diff first.

git reset moves the branch, and the mode decides what follows it

git reset <commit> moves the branch you are on, and HEAD with it, to another commit, so the commits after that one are no longer on the branch. The mode then decides what else is reset. HEAD~1 names the commit before HEAD. This session makes two commits, copies the repository three times and runs one mode in each copy:

from gitsession import session

session(r"""
git init -q -b main canteen
cd canteen
printf 'idli\nvada\n' > menu.txt
git add menu.txt
git commit -q -m "Add the breakfast menu"
printf 'idli\nvada\ndosa\n' > menu.txt
printf 'idli 30\nvada 25\ndosa 40\n' > prices.txt
git add menu.txt prices.txt
git commit -q -m "Add dosa and a price list"
git log --oneline
# Three copies of the same repository, one for each mode
cd ..
cp -R canteen soft
cp -R canteen mixed
cp -R canteen hard
# --soft moves only the branch: the undone commit's changes are still staged
cd ~/soft
git reset --soft HEAD~1
git log --oneline
git status --short
# --mixed, the default, also copies the commit into the index: the changes are only in the files
cd ~/mixed
git reset HEAD~1
git status --short
# --hard also copies it over the files: the changes are in none of the three trees
cd ~/hard
git reset --hard HEAD~1
git status --short
ls
""")

$ git init -q -b main canteen
$ cd canteen
$ printf 'idli\nvada\n' > menu.txt
$ git add menu.txt
$ git commit -q -m "Add the breakfast menu"
$ printf 'idli\nvada\ndosa\n' > menu.txt
$ printf 'idli 30\nvada 25\ndosa 40\n' > prices.txt
$ git add menu.txt prices.txt
$ git commit -q -m "Add dosa and a price list"
$ git log --oneline
f3a1ffe Add dosa and a price list
eeaba07 Add the breakfast menu
# Three copies of the same repository, one for each mode
$ cd ..
$ cp -R canteen soft
$ cp -R canteen mixed
$ cp -R canteen hard
# --soft moves only the branch: the undone commit's changes are still staged
$ cd ~/soft
$ git reset --soft HEAD~1
$ git log --oneline
eeaba07 Add the breakfast menu
$ git status --short
M  menu.txt
A  prices.txt
# --mixed, the default, also copies the commit into the index: the changes are only in the files
$ cd ~/mixed
$ git reset HEAD~1
Unstaged changes after reset:
M	menu.txt
$ git status --short
 M menu.txt
?? prices.txt
# --hard also copies it over the files: the changes are in none of the three trees
$ cd ~/hard
$ git reset --hard HEAD~1
HEAD is now at eeaba07 Add the breakfast menu
$ git status --short
$ ls
menu.txt

Step through the three copies and watch how far down the three trees each mode reaches:

Every mode moves the branch and HEAD; they differ in what else they reset:

Watch prices.txt, the file the undone commit added. After --soft it is still staged (A). After --mixed it is untracked (??), because the index no longer lists it. After --hard the file is gone from the folder, because a tracked file that the target commit does not have is deleted.

Before it moves the branch, every reset stores the old position in ORIG_HEADORIG_HEAD: A reference that git reset, git rebase, git merge and git am set to where HEAD was before they moved it, so git reset --hard ORIG_HEAD undoes the most recent of those moves. More in “Recover lost commits with the reflog”, so git reset --hard ORIG_HEAD undoes a reset you regret straight away. It cannot bring back uncommitted edits that the reset overwrote. The reflogreflog: A log of every position that HEAD and each branch has had in one repository, newest first. It is never pushed or cloned. Its entries are named like HEAD@{2}, and apart from stashes they expire after 90 days by default, or 30 for commits no branch reaches. More in “Recover lost commits with the reflog” keeps a longer memory of where the branch has been, and the reflog lesson later in this module shows how to use it.

A keep reset refuses where a hard reset would overwrite your edits

--hard overwrites local edits without asking. --keep moves the branch and updates the files that the reset has to change, but refuses when one of those files has an edit you have not committed:

from gitsession import session

session(r"""
git init -q -b main canteen
cd canteen
printf 'idli\nvada\n' > menu.txt
printf 'Open 7 to 10\n' > hours.txt
git add menu.txt hours.txt
git commit -q -m "Add the menu and the opening hours"
printf 'idli\nvada\ndosa\n' > menu.txt
git commit -q -am "Add dosa"
# An unfinished edit in a file that the last commit did not change
printf 'Open 7 to 11\n' > hours.txt
git reset --keep HEAD~1
git log --oneline
git status --short
# Commit dosa again, then leave an edit in menu.txt, which the reset has to change
printf 'idli\nvada\ndosa\n' > menu.txt
git commit -q -m "Add dosa" menu.txt
printf 'idli\nvada\ndosa\nupma\n' > menu.txt
! git reset --keep HEAD~1
git status --short
""")

$ git init -q -b main canteen
$ cd canteen
$ printf 'idli\nvada\n' > menu.txt
$ printf 'Open 7 to 10\n' > hours.txt
$ git add menu.txt hours.txt
$ git commit -q -m "Add the menu and the opening hours"
$ printf 'idli\nvada\ndosa\n' > menu.txt
$ git commit -q -am "Add dosa"
# An unfinished edit in a file that the last commit did not change
$ printf 'Open 7 to 11\n' > hours.txt
$ git reset --keep HEAD~1
$ git log --oneline
f5776ef Add the menu and the opening hours
$ git status --short
 M hours.txt
# Commit dosa again, then leave an edit in menu.txt, which the reset has to change
$ printf 'idli\nvada\ndosa\n' > menu.txt
$ git commit -q -m "Add dosa" menu.txt
$ printf 'idli\nvada\ndosa\nupma\n' > menu.txt
$ git reset --keep HEAD~1
error: Entry 'menu.txt' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'HEAD~1'.
[exit status 128]
$ git status --short
 M hours.txt
 M menu.txt

The first reset removed the dosa commit and kept the unfinished edit of hours.txt, which that commit had not touched. The second had to change menu.txt, which had an uncommitted line of upma, so Git stopped with exit status 128 and changed nothing at all. Commit, stash or discard that edit, then reset again. Wherever you would type --hard while uncommitted work is around, --keep is the safer habit.

--keep also trusts the file timestamps that the index recorded. If a tool rewrites a file without changing its content, Git 2.54.0 can refuse with the same error although nothing has changed. Commands that refresh the index, such as git status and git diff, clear the problem, so run one and reset again.

Four modes on fifteen starting states, measured

The git reset manual has tables of what each mode does to a file in each state. This program builds every mix of states for one file, runs the four modes of this lesson on it with real Git and prints what happened. The fifth mode, --merge, mainly exists to clear the unmerged entries a conflict leaves in the index, and it too refuses rather than overwrite an unstaged edit. C is the file in HEAD, D in the commit you reset to, B a change you staged and A a change you made only in the working tree:

"""Runs every git reset mode on one file in each mix of states, with real Git, and prints what each mode did.

The file is menu.txt. C is its content in the last commit (HEAD), D its content in the commit you reset to (the
target), B a change you staged and A a change you only made in the working tree. Every run starts from a fresh
copy of the same repository, so no run can affect another.
"""

import hashlib
import os
import shutil
import subprocess
import tempfile

from gitsession import git_env

MODES = ["soft", "mixed", "hard", "keep"]
work = tempfile.mkdtemp(prefix="reset-table-")


def git(repo, *args):
    return subprocess.run(["git", *args], cwd=repo, env=git_env(work), capture_output=True, text=True)


def put(repo, content):
    with open(os.path.join(repo, "menu.txt"), "w") as f:
        f.write(content + "\n")


def blob_id(content):
    """The ID Git gives a file's content: the SHA-1 of "blob <size>", a zero byte, then the bytes."""
    data = (content + "\n").encode()
    return hashlib.sha1(b"blob %d\0" % len(data) + data).hexdigest()


# One repository with two commits: the target (menu.txt holds D), then HEAD (menu.txt holds C).
template = os.path.join(work, "template")
os.mkdir(template)
git(template, "init", "-q", "--template=", "-b", "main")  # no sample hooks: smaller copies
put(template, "D")
git(template, "add", "menu.txt")
git(template, "commit", "-q", "-m", "target")
put(template, "C")
git(template, "commit", "-q", "-am", "head")
commit = {git(template, "rev-parse", rev).stdout.strip(): name for rev, name in [("HEAD", "C"), ("HEAD~1", "D")]}
blob = {blob_id(x): x for x in "ABCD"}


def prepare(working, index):
    """A copy of the template with `index` staged and `working` left in the file."""
    repo = tempfile.mkdtemp(dir=work)
    shutil.copytree(template, repo, dirs_exist_ok=True)
    put(repo, index)
    git(repo, "add", "menu.txt")
    put(repo, working)
    return repo


def reset(prepared, target, mode):
    """Resets a copy of the prepared repository and reads the three trees: the file, the index entry and HEAD."""
    repo = tempfile.mkdtemp(dir=work)
    shutil.copytree(prepared, repo, dirs_exist_ok=True)
    # A copied file has a new timestamp: refresh the index first, as git status or git diff would
    git(repo, "update-index", "-q", "--refresh")
    if git(repo, "reset", "-q", f"--{mode}", "HEAD" if target == "C" else "HEAD~1").returncode != 0:
        return "refused"
    with open(os.path.join(repo, "menu.txt")) as f:
        now_working = f.read().strip()
    head_id, index_id = git(repo, "rev-parse", "HEAD", ":menu.txt").stdout.split()
    return f"{now_working} {blob[index_id]} {commit[head_id]}"


print("Before the reset          | After: working tree, index, HEAD")
print("working index HEAD target |", " | ".join(f"--{m:<5}" for m in MODES))
for target in ["D", "C"]:
    for index in dict.fromkeys(["C", "B", target]):
        for working in dict.fromkeys([index, "C", "A", target]):
            prepared = prepare(working, index)
            results = [reset(prepared, target, m) for m in MODES]
            print(f"   {working}      {index}     C     {target}    |", " | ".join(f"{r:<7}" for r in results))
shutil.rmtree(work)

Before the reset          | After: working tree, index, HEAD
working index HEAD target | --soft  | --mixed | --hard  | --keep 
   C      C     C     D    | C C D   | C D D   | D D D   | D D D  
   A      C     C     D    | A C D   | A D D   | D D D   | refused
   D      C     C     D    | D C D   | D D D   | D D D   | refused
   B      B     C     D    | B B D   | B D D   | D D D   | refused
   C      B     C     D    | C B D   | C D D   | D D D   | refused
   A      B     C     D    | A B D   | A D D   | D D D   | refused
   D      B     C     D    | D B D   | D D D   | D D D   | refused
   D      D     C     D    | D D D   | D D D   | D D D   | D D D  
   C      D     C     D    | C D D   | C D D   | D D D   | C D D  
   A      D     C     D    | A D D   | A D D   | D D D   | A D D  
   C      C     C     C    | C C C   | C C C   | C C C   | C C C  
   A      C     C     C    | A C C   | A C C   | C C C   | A C C  
   B      B     C     C    | B B C   | B C C   | C C C   | B C C  
   C      B     C     C    | C B C   | C C C   | C C C   | C C C  
   A      B     C     C    | A B C   | A C C   | C C C   | A C C  

Read each row from left to right: the state before the reset, then the working tree, index and HEAD after each mode. --soft only ever changes the last letter, --mixed the last two and --hard all three. The --keep column is the one to study. When HEAD and the target hold the same version, in the last five rows, --keep acts like --mixed and keeps every edit. When they differ, it refuses as soon as the file has a staged or unstaged change against HEAD, unless the index already holds the target’s version. Then the working tree file is left exactly as it was: in the row that starts C D C D, the file still holds C afterwards. The exercise at the end of this lesson turns this table into code.

Amending replaces the last commit with a new one

git commit --amend makes a new commit from the index and puts it in place of the last one, with the same parent and the same author. Use it for a typo in the message, or for a file that belonged in the commit:

from gitsession import session

session(r"""
git init -q -b main canteen
cd canteen
printf 'idli\nvada\n' > menu.txt
git add menu.txt
git commit -q -m "Add the brekfast menu"
git log --oneline
# Fix the message, and add the price list that was meant to be in the same commit
printf 'idli 30\nvada 25\n' > prices.txt
git add prices.txt
git commit -q --amend -m "Add the breakfast menu and prices"
git log --oneline
git show --stat --format=%s HEAD
# One more file, same message: --no-edit keeps it
printf 'Open 7 to 10\n' > hours.txt
git add hours.txt
git commit -q --amend --no-edit
git log --oneline
# The commits that were replaced still exist, and the reflog remembers them
git reflog
""")

$ git init -q -b main canteen
$ cd canteen
$ printf 'idli\nvada\n' > menu.txt
$ git add menu.txt
$ git commit -q -m "Add the brekfast menu"
$ git log --oneline
cd5a276 Add the brekfast menu
# Fix the message, and add the price list that was meant to be in the same commit
$ printf 'idli 30\nvada 25\n' > prices.txt
$ git add prices.txt
$ git commit -q --amend -m "Add the breakfast menu and prices"
$ git log --oneline
35b7257 Add the breakfast menu and prices
$ git show --stat --format=%s HEAD
Add the breakfast menu and prices

 menu.txt   | 2 ++
 prices.txt | 2 ++
 2 files changed, 4 insertions(+)
# One more file, same message: --no-edit keeps it
$ printf 'Open 7 to 10\n' > hours.txt
$ git add hours.txt
$ git commit -q --amend --no-edit
$ git log --oneline
8a89640 Add the breakfast menu and prices
# The commits that were replaced still exist, and the reflog remembers them
$ git reflog
8a89640 HEAD@{0}: commit (amend): Add the breakfast menu and prices
35b7257 HEAD@{1}: commit (amend): Add the breakfast menu and prices
cd5a276 HEAD@{2}: commit (initial): Add the brekfast menu

The commit’s ID changed with each amend: cd5a276 became 35b7257, then 8a89640. Step through the two amends and watch where main points, and what happens to the commits it leaves:

Git never changes a commit: the old ones were left behind, and the reflog still lists them. The manual describes --amend as a rough equivalent of git reset --soft HEAD~1 followed by a commit that starts from the old message, which matches the output: the branch moved off the old commit and onto a new one. --no-edit keeps the message as it was. Because the ID changes, amending a commit that other people have already pulled rewrites shared history, just as a reset does.

A hard reset destroys only what Git never stored

Most mistakes in Git can be undone, but one cannot. This session makes three kinds of work, a commit, two staged new files and a later edit that is not staged, and then runs git reset --hard HEAD~1:

from gitsession import session

session(r"""
git init -q -b main canteen
cd canteen
printf 'idli\nvada\n' > menu.txt
git add menu.txt
git commit -q -m "Add the breakfast menu"
# Three kinds of work: a commit, two staged new files and a later edit that is not staged
printf 'idli\nvada\ndosa\n' > menu.txt
git commit -q -am "Add dosa"
printf 'idli 30\nvada 25\n' > prices.txt
git add prices.txt
printf 'Open 7 to 10\n' > hours.txt
git add hours.txt
printf 'Open 7 to 11\n' > hours.txt
git status --short
git reset --hard HEAD~1
git status --short
# The commit is still in the reflog
git log --oneline -1 HEAD@{1}
# git add stored both staged files; --lost-found lists what nothing points to, and ignores the reflog
git fsck --lost-found
cat .git/lost-found/other/*
# "Open 7 to 11" was never staged, so Git never stored it: nothing can bring that edit back
""")

$ git init -q -b main canteen
$ cd canteen
$ printf 'idli\nvada\n' > menu.txt
$ git add menu.txt
$ git commit -q -m "Add the breakfast menu"
# Three kinds of work: a commit, two staged new files and a later edit that is not staged
$ printf 'idli\nvada\ndosa\n' > menu.txt
$ git commit -q -am "Add dosa"
$ printf 'idli 30\nvada 25\n' > prices.txt
$ git add prices.txt
$ printf 'Open 7 to 10\n' > hours.txt
$ git add hours.txt
$ printf 'Open 7 to 11\n' > hours.txt
$ git status --short
AM hours.txt
A  prices.txt
$ git reset --hard HEAD~1
HEAD is now at eeaba07 Add the breakfast menu
$ git status --short
# The commit is still in the reflog
$ git log --oneline -1 HEAD@{1}
23afb42 Add dosa
# git add stored both staged files; --lost-found lists what nothing points to, and ignores the reflog
$ git fsck --lost-found
dangling commit 23afb42882949ecb3bf0ddf8517fe8edc7bc1e09
dangling blob cc41b8c6ff4a1e741bb41c3e26daf27d7047bd53
dangling blob 528b91ed59ebb54c037c8eb5b47c9fc4377e9e61
$ cat .git/lost-found/other/*
Open 7 to 10
idli 30
vada 25
# "Open 7 to 11" was never staged, so Git never stored it: nothing can bring that edit back

What happened to each kind of work, and the way back where there is one:

git add stored each staged file as a blob, and git fsck --lost-found lists the objects that nothing points to and copies the danglingdangling object: An object in the repository that nothing points to: no reference, index entry or other object uses it, such as a blob that was staged but never committed. git fsck lists such objects until garbage collection deletes them. More in “Recover lost commits with the reflog” blobs into .git/lost-found/other/. The file names are lost, but the contents are there, hours.txt as it was when it was staged. --lost-found ignores the reflog, which is why it lists the commit as well. Open 7 to 11 was never staged, so Git never stored it, and no Git command can bring it back.

So before any reset with --hard while uncommitted work is in the folder, run git status and keep what matters. git stash push --include-untracked sets everything aside, as the next lesson, on stash and worktrees, shows. A patch works too: git diff HEAD > before-reset.patch saves every staged and unstaged change to tracked files, though not untracked ones, and git apply before-reset.patch puts them back.

git clean deletes untracked files, so look before you delete

git restore and git reset leave untracked files alone. git clean deletes them, so run it with -n, a dry run, first: it lists what would go and deletes nothing. This college fest site has an untracked folder of drafts and a to-do list, and an ignored build folder and log file:

from gitsession import session

session(r"""
git init -q -b main fest-site
cd fest-site
printf 'build/\n*.log\n' > .gitignore
printf '<h1>College fest</h1>\n' > index.html
git add .gitignore index.html
git commit -q -m "Start the fest site"
mkdir build drafts
printf '<h1>College fest</h1>\n' > build/index.html
printf 'Ideas for the quiz night\n' > drafts/quiz.txt
printf 'started\n' > server.log
printf 'Book the hall\n' > todo.txt
git status --short --ignored
! git clean
git clean -n
git clean -n -d
git clean -n -d -x
git clean -n -d -X
git clean -f -d
git status --short --ignored
""")

$ git init -q -b main fest-site
$ cd fest-site
$ printf 'build/\n*.log\n' > .gitignore
$ printf '<h1>College fest</h1>\n' > index.html
$ git add .gitignore index.html
$ git commit -q -m "Start the fest site"
$ mkdir build drafts
$ printf '<h1>College fest</h1>\n' > build/index.html
$ printf 'Ideas for the quiz night\n' > drafts/quiz.txt
$ printf 'started\n' > server.log
$ printf 'Book the hall\n' > todo.txt
$ git status --short --ignored
?? drafts/
?? todo.txt
!! build/
!! server.log
$ git clean
fatal: clean.requireForce is true and -f not given: refusing to clean
[exit status 128]
$ git clean -n
Would remove todo.txt
$ git clean -n -d
Would remove drafts/
Would remove todo.txt
$ git clean -n -d -x
Would remove build/
Would remove drafts/
Would remove server.log
Would remove todo.txt
$ git clean -n -d -X
Would remove build/
Would remove server.log
$ git clean -f -d
Removing drafts/
Removing todo.txt
$ git status --short --ignored
!! build/
!! server.log

Without -f or -n, git clean refused, because the setting clean.requireForce is true unless you change it. The dry runs then showed which option reaches which of the four:

-x deletes ignored files as well as untracked ones, and -X deletes only ignored files, a quick way to clear build output and keep your own notes. -f -d deleted drafts/ and todo.txt and left the ignored files, as the last status shows. -i shows what would go and lets you choose, by number, by pattern or one file at a time. An untracked file that git clean deleted was never in Git, so nothing in Git can bring it back.

Pick the undo from where the change is

Find where your change is, then choose between keeping the work and throwing it away. Answer the three questions for a change of your own, and the table rules out the commands that would do the wrong thing, with the reason:

In short, by where the change is:

• Not staged. Keep: there is nothing to undo, and git stash push sets it aside. Throw away: git restore <file>.
• Staged. Keep: git restore --staged <file>. Throw away: git restore --staged --worktree <file>.
• Untracked. Keep: git stash push --include-untracked. Throw away: git clean -n, then git clean -f.
• The last commit, not pushed. Keep: stage a fix, then git commit --amend. Throw away: git reset --keep HEAD~1.
• Several commits, not pushed. Keep: git reset --soft HEAD~<n> leaves the changes staged, git reset HEAD~<n> unstaged. Throw away: git reset --keep HEAD~<n>, or --hard when nothing is uncommitted.
• Commits on a shared branch. Either way: git revert <commit>, a new commit that undoes it. Rewriting shared history needs the team’s agreement.

Two checks keep the guide safe. Before anything with --hard or git clean -f, run git status and read it. Before you rewrite commits, look at what git status says about your branch and its upstream, for example “ahead of ‘origin/main’ by 2 commits”: only those commits are yours alone to rewrite.

Practise: predict what a reset does

The rules of these four modes fit in a dozen lines of code, and writing them is a good check that you can predict a reset before you run it. The sample tests are the fifteen rows that reset_table.py measured:

def reset_file(mode, working, index, head, target):
    """The file's (working, index, head) after git reset --<mode> <target>, or None when Git refuses."""
    # Replace this line with your code.
    return (working, index, head)

from reset_model import reset_file

# Recorded by reset_table.py with real Git: the file's content before the reset (working tree, index, HEAD,
# target), then (working tree, index, HEAD) after --soft, --mixed, --hard and --keep; None: Git refused.
ROWS = [
    ("C", "C", "C", "D", ("C", "C", "D"), ("C", "D", "D"), ("D", "D", "D"), ("D", "D", "D")),
    ("A", "C", "C", "D", ("A", "C", "D"), ("A", "D", "D"), ("D", "D", "D"), None),
    ("D", "C", "C", "D", ("D", "C", "D"), ("D", "D", "D"), ("D", "D", "D"), None),
    ("B", "B", "C", "D", ("B", "B", "D"), ("B", "D", "D"), ("D", "D", "D"), None),
    ("C", "B", "C", "D", ("C", "B", "D"), ("C", "D", "D"), ("D", "D", "D"), None),
    ("A", "B", "C", "D", ("A", "B", "D"), ("A", "D", "D"), ("D", "D", "D"), None),
    ("D", "B", "C", "D", ("D", "B", "D"), ("D", "D", "D"), ("D", "D", "D"), None),
    ("D", "D", "C", "D", ("D", "D", "D"), ("D", "D", "D"), ("D", "D", "D"), ("D", "D", "D")),
    ("C", "D", "C", "D", ("C", "D", "D"), ("C", "D", "D"), ("D", "D", "D"), ("C", "D", "D")),
    ("A", "D", "C", "D", ("A", "D", "D"), ("A", "D", "D"), ("D", "D", "D"), ("A", "D", "D")),
    ("C", "C", "C", "C", ("C", "C", "C"), ("C", "C", "C"), ("C", "C", "C"), ("C", "C", "C")),
    ("A", "C", "C", "C", ("A", "C", "C"), ("A", "C", "C"), ("C", "C", "C"), ("A", "C", "C")),
    ("B", "B", "C", "C", ("B", "B", "C"), ("B", "C", "C"), ("C", "C", "C"), ("B", "C", "C")),
    ("C", "B", "C", "C", ("C", "B", "C"), ("C", "C", "C"), ("C", "C", "C"), ("C", "C", "C")),
    ("A", "B", "C", "C", ("A", "B", "C"), ("A", "C", "C"), ("C", "C", "C"), ("A", "C", "C")),
]


def check(mode, column):
    for row in ROWS:
        working, index, head, target = row[:4]
        got = reset_file(mode, working, index, head, target)
        assert got == row[column], f"--{mode} with {working} {index} {head} {target}: expected {row[column]}, got {got}"


def test_soft():
    """--soft moves only the branch"""
    check("soft", 4)


def test_mixed():
    """--mixed also resets the index"""
    check("mixed", 5)


def test_hard():
    """--hard resets all three trees"""
    check("hard", 6)


def test_keep():
    """--keep keeps local changes, or refuses when it would have to overwrite them"""
    check("keep", 7)

The sessions are Python programs that drive real Git through the helper below, which prints each command after a $ with whatever Git wrote back, and adds [exit status 128] where a command was meant to fail. It fixes the author and the clock and works in a throwaway home folder, so python3 restore.py, run next to gitsession.py, prints this page’s commit IDs; the same commands typed by hand give IDs of your own:

"""Plays a terminal session with real Git: each command is printed after "$ ", then what it printed.

Every session starts in a new, empty folder that is also its home folder ("~" in the output), so your own Git
settings play no part, and GIT_CONFIG_NOSYSTEM=1 skips the computer's system-wide settings file. Commits get a
fixed author, Asha Rao, and a fixed clock that moves on one minute per line. A commit's ID covers its author and
time, so the IDs printed here are the ones you get when you run the file yourself. A session started with
fixed_time=False uses the real time instead, for commands whose behaviour depends on how old an entry is.

Each line of a script is one /bin/sh command; the session itself does "cd" and keeps "NAME=$(command)" for the
lines after it, as a shell would. A line that starts with "! " is meant to fail: its exit status is shown. Any
other command that fails stops the session. The folder is deleted at the end.
"""

import atexit
import functools
import os
import re
import shutil
import subprocess
import sys
import tempfile

# The first commit time, in seconds since 1970, and India's offset from UTC (Git's own date format).
START = 1767240000
ZONE = "+0530"


@functools.cache
def _git_folder():
    """The folder that holds the git program. On macOS, /usr/bin/git only starts the Command Line Tools' git."""
    found = subprocess.run(["git", "--exec-path"], capture_output=True, text=True).stdout.strip()
    return found if found and os.path.isfile(os.path.join(found, "git")) else None


def git_env(home, minute=0, fixed_time=True):
    """The environment every command runs with: no personal settings, a fixed author and a fixed time."""
    folder = _git_folder()
    stamp = f"@{START + 60 * minute} {ZONE}"
    env = {
        "PATH": os.pathsep.join(p for p in (folder, os.environ.get("PATH", "/usr/bin:/bin")) if p),
        "HOME": home,
        "XDG_CONFIG_HOME": os.path.join(home, ".config"),
        "GIT_CONFIG_NOSYSTEM": "1",
        "GIT_AUTHOR_NAME": "Asha Rao",
        "GIT_AUTHOR_EMAIL": "asha@example.com",
        "GIT_COMMITTER_NAME": "Asha Rao",
        "GIT_COMMITTER_EMAIL": "asha@example.com",
        "GIT_AUTHOR_DATE": stamp,
        "GIT_COMMITTER_DATE": stamp,
        "LANG": "C",
        "LC_ALL": "C",
        "TERM": "dumb",
    }
    if not fixed_time:
        del env["GIT_AUTHOR_DATE"], env["GIT_COMMITTER_DATE"]
    return env


def session(script, fixed_time=True):
    """Runs each line of the script in order, starting in the home folder."""
    home = tempfile.mkdtemp(prefix="git-lesson-")
    atexit.register(shutil.rmtree, home, True)
    spellings = sorted({home, os.path.realpath(home)}, key=len, reverse=True)
    saved = {}

    def tidy(text):
        for spelling in spellings:
            text = text.replace(spelling, "~")
        return text

    cwd = home
    for minute, line in enumerate(script.strip().splitlines()):
        command = line.strip()
        if not command:
            continue
        if command.startswith("#"):
            print(command)
            continue
        should_fail = command.startswith("! ")
        if should_fail:
            command = command[2:]
        print(f"$ {command}")
        if command.startswith("cd "):
            target = command[3:].strip()
            if target == "~" or target.startswith("~/"):
                target = home + target[1:]
            cwd = os.path.normpath(os.path.join(cwd, target))
            continue
        keep = re.fullmatch(r"([A-Za-z_]\w*)=\$\((.+)\)", command)
        done = subprocess.run(
            keep.group(2) if keep else command,
            shell=True,
            cwd=cwd,
            env={**git_env(home, minute, fixed_time), **saved},
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE if keep else subprocess.STDOUT,
            text=True,
        )
        if keep:
            saved[keep.group(1)] = done.stdout.strip()
            print(tidy(done.stderr), end="")
        else:
            print(tidy(done.stdout), end="")
        if done.returncode != 0:
            print(f"[exit status {done.returncode}]")
            if not should_fail:
                sys.exit(1)
        elif should_fail:
            sys.exit(f"{command!r} was meant to fail, and it worked")

Then test yourself on the seven ideas of this lesson. Every answer is explained at once, and the questions keep returning to the idea you have got wrong most often:

Interview questions

Warm-up (fresher): What is the difference between git reset --soft, --mixed and --hard?

All three move the current branch, and HEAD with it, to the commit you name, so the commits after it leave the branch. They differ in what else they reset. --soft stops there: the index and the working tree keep their contents, so the undone changes show as staged, ready to commit again. --mixed, the default, also resets the index, so the changes stay in your files but are unstaged, and a file the undone commit added becomes untracked. --hard also overwrites the working tree, so the changes are gone from all three trees. Uncommitted edits that --hard overwrites cannot be recovered, while the undone commits stay in the reflog for a while. With local edits to protect, --keep is the safer choice, because it refuses instead of overwriting them.

Two harder questions start from this lesson’s sessions: commits on the wrong branch, one of them already pushed, and a commit that has to become two.

Key takeaways

• Every undo starts with where the change is: in the working tree, in the index, in a local commit or in a pushed commit.
• git restore <file> copies the index’s version over the file and --staged copies HEAD’s version into the index, and neither moves a branch.
• git reset moves the branch: --soft keeps the changes staged, --mixed keeps them in the files, --hard deletes them, and --keep refuses rather than overwrite a local edit.
• git commit --amend replaces the last commit with a new one, and the replaced commit stays in the reflog.
• After a hard reset, commits and staged contents can still be found, but an edit that was never staged is gone, and so is an untracked file that git clean -f deleted, which is why git clean -n comes first.
• Pushed commits are undone with git revert, which adds a commit, rather than with a reset or an amend.