Going back for real

"Git is the undo button" was true enough to get started. It is now worth being precise, because there are three different situations that people all call "undo", they need three different commands, and one of them permanently destroys work.

Situation 1 — you changed files and have not committed

You edited, it went badly, nothing is committed. You want the last committed version back.

git restore src/app.js       # one file
git restore .                # everything not yet committed

Your edits since the last commit are gone, for real. That is what you asked for, and it is why "commit before you experiment" is the whole habit.

Situation 2 — the bad change is already committed

You committed, and it was wrong.

git log --oneline            # find the commit — the short id on the left
git revert a1b2c3d           # undo it

revert does not delete the commit. It writes a new commit that is the opposite of the old one. History grows; nothing disappears.

That sounds like bureaucracy and is actually the point. The history stays true — it records that you did a thing and then undid it, which is what happened. And because nothing was rewritten, it is safe even when your code is on GitHub or someone else has it. This is the undo you will reach for most.

Situation 3 — the command that loses work

git reset --hard a1b2c3d

This moves your branch back and throws away everything after it. Commits, edits, all of it. There is no prompt, no confirmation, and no undo button for the undo button.

It has real uses. It is also the one command in this course that can lose an afternoon, so the rule is simple: if you are not certain, use revert. It gets you the same working state and it cannot cost you anything.

Look before you go back

git log --oneline -5         # the last five commits
git show HEAD                # what the most recent commit changed

Two commands, ten seconds, and you are undoing something you have actually looked at rather than something you assume you remember. git show HEAD prints exactly the last commit; git diff HEAD~1 looks similar and is not the same thing — it compares your working files against the commit before last, so any edits you have not committed yet get mixed into what you are reading.

What this is for

From course 1 onward you accept changes you did not write. That is only reasonable because going back is cheap and certain. Commit before the assistant touches anything, and every change it makes becomes a proposal you can decline afterwards rather than a decision you make in advance.

Try it now

Commit a change you know is wrong — delete a function that something else calls. Confirm it breaks. Then git revert it and confirm it works again. Now run git log --oneline and read the two entries. Notice that the history tells the truth about what you did, which is exactly what you want when the thing you broke was three weeks ago.