git reset: rewinding commits

Taking back a commit

git restore handles uncommitted changes. What if you already committed and regret it? git reset moves your current position, HEAD from lesson 3-1, back to an earlier commit.

First, the address notation: HEAD~1 means "one commit before HEAD", HEAD~2 means two before, and so on. So the everyday incantation is:

$ git reset --soft HEAD~1

read as "move me back one commit." The commit disappears from git log, but the changes inside it don't vanish into thin air. Where they land depends on the mode flag, and that's the entire trick to understanding reset.

The three modes

Memory hook: soft is the gentlest landing (everything still staged, ready to re-commit), mixed drops the changes back to your desk, hard throws them in the shredder.

--hard is the second dangerous command of the unit. Before running it, say out loud what you expect to lose. (Lesson 4-3 reveals a safety net that can often save you anyway.)

Worked example: re-slicing a bad commit

Here is the reset engineers actually run weekly. You hurried and committed two unrelated changes as one blob:

$ git log --oneline
9c8b7a6 wip stuff        ← a bug fix AND a new recipe, mashed together
a1b2c3d Add pancake recipe

Lesson 2-3's rule says one logical change per commit, so unpack it:

$ git reset HEAD~1        # mixed: commit undone, both changes back, unstaged
$ git add soup.txt
$ git commit -m "Fix soup salt amount"
$ git add cake.txt
$ git commit -m "Add chocolate cake recipe"

The sloppy commit is gone and two clean, honest commits stand in its place. Nothing was ever at risk: mixed reset never touches the working directory, it only rewinds history and clears the staging area so you can re-stage in better slices.