Topic 17

I Committed Too Early

Undo

You committed, and half a second later you saw it: a typo in the message, or the one file you forgot to stage. It is the most ordinary mistake in Git and it happens to everyone daily.

git commit --amend replaces that last commit with a corrected one. The word replaces is doing real work in that sentence, and it is why this page ends with a rule about when not to use it.

Fixing the message

Replace the last commit's message

git commit --amend -m "Fix the meeting time on the home page"

The commit's contents are unchanged; only the message is different. Run git log --oneline and you will see the corrected text.

Adding the file you forgot

More common, and more useful. You committed the new sightings page and forgot to stage its stylesheet:

Fold the forgotten file into the previous commit

git add style.css
git commit --amend --no-edit

--no-edit means "keep the message as it is". The forgotten file joins the commit, the message stays, and the history looks like the mistake never happened.

What actually happened

Look closely at the log before and after:

The hash changed

c8d1e07 Fix the meeting time on the home page      <- before
7f4b2a9 Fix the meeting time on the home page      <- after

Same message, different commit. As Chapter 3 explained, a commit's hash comes from its contents, so a commit with anything changed is a different commit. Git built a replacement and moved your branch onto it.

The original is not destroyed. It is simply no longer part of the chain, and the reflog at the end of this chapter can still find it. But it is no longer the commit anyone will see.

Amend replaces rather than edits

a3f9c21Add the home page

→

5b2a9f3Add basic styling

→

c8d1e07replaced — orphaned

→

7f4b2a9the amended commit

The rule

Amend only a commit you have not pushed.

On your own machine, replacing your last commit affects nobody. Once that commit has been sent to GitHub and someone else has it, replacing it means your history and theirs disagree about a commit they both think exists — and sorting that out is a genuine mess, covered honestly in Chapter 10.

The window where amend is safe is exactly the window where you use it: the seconds and minutes right after committing, before anything leaves your laptop. The two line up on purpose. It is what the command is for.

When it is too late

If the commit is already pushed, you have two honest options. Use git revert — the next topic — to add a commit that undoes it. Or, if the problem is only a slightly imperfect message, leave it alone. A history with one awkward message is fine. A history that disagrees with everyone else's copy is not.

Only the last one

Amend reaches exactly one commit back. Fixing something three commits ago means rewriting a stretch of history, which is interactive rebase — a real tool, genuinely useful, and firmly in the deep dive rather than here. For now: catch it immediately, or revert it.

Common Confusions

"Amend edits the commit." It builds a replacement with a new hash and moves the branch onto it. The original is orphaned rather than modified, which is why the reflog can still find it.
"Amend is dangerous." It is completely safe on unpushed commits, which is nearly every use of it. The danger is entirely about commits other people already have.
"I can amend any recent commit." Only the most recent one. Anything further back is history rewriting, and this book does not teach it.
"--no-edit means the commit will have no message." It means "keep the existing message". Without it, Git opens an editor so you can change the message too.

Why It Matters

Amend fixes the two most common commit mistakes — a wrong message and a forgotten file — and both are noticed within seconds, which is exactly the window where amending is safe.
The pushed-versus-unpushed rule introduced here is the same rule that governs everything in Chapter 10, so learning it on a harmless command is the cheap way to learn it.
Seeing the hash change makes Chapter 3's "a commit cannot be edited" concrete rather than theoretical.

Knowledge Check

What does git commit --amend do to the previous commit?

It builds a replacement with a new hash and then moves the branch onto it
It edits the existing commit in place, keeping the same identifying hash
It creates a second commit that describes the correction to the first one
It deletes the previous commit permanently, removing it from the repository

When is amending completely safe?

While the commit still exists only on your own machine and nowhere else
Whenever the change involves only the commit message and not any files
Whenever it is done within a few minutes of making the original commit
Whenever the branch you are working on has not yet been merged anywhere

You committed and forgot to stage style.css. What is the two-command fix?

Stage it with git add style.css, then git commit --amend --no-edit
git restore style.css, then git commit -m with the original message
git revert on the last commit, then commit both files together again
git add style.css on its own, since Git folds it into the last commit

The commit you want to fix is three commits back. What does this book tell you to do?

Use git revert, or accept it, since reaching further back is out of scope
Run git commit --amend three times to step backwards through the history
Delete the last three commits and remake them with the correction included
Edit the file in the old commit directly, since commit contents can be changed

You got correct