My Last Commit Message Is Wrong, or I Left a File Out

You made a commit a minute ago and it is not right. Perhaps the message says nothing useful, or you meant to include a file and forgot it. The commit is still only on your machine.

Git can replace that commit with a better one. The catch is in the word replace, and this lesson is as much about when to use it as how.

Read what you actually committed

git log
git status

Two problems. The newest commit has the message update, which tells a future reader nothing. And packing.txt, a list of boots, map and compass, is sitting untracked beside it. It was meant to go in.

Fix both in one move

git commit --amend replaces the newest commit with a new one built from whatever is staged now, plus a message you supply.

Read that once more, because it is the trap in this command: everything staged goes in, not only the file you just added. A file you staged an hour ago and forgot about is about to become part of a commit whose message says nothing about it.

So the habit worth building is to look before you amend. git status at the top of this lesson shows scratch.tmp safely untracked after the preceding lesson and nothing in the staging area. That is the safe starting point. Stage only the forgotten file and amend:

git add packing.txt
git commit --amend -m "Add the packing list and the ranger note"
git log
git status

git add packing.txt stages the file, exactly as it would for an ordinary commit. git commit --amend then makes a commit from the staged contents and uses it instead of the previous one rather than after it. -m supplies the new message, the same as it does for a normal commit.

git log now shows the better message, and the count of commits has not gone up. git status no longer mentions packing.txt, because it is committed rather than lying around untracked.

git status is not empty, though, and it should not be. scratch.tmp is still there as an untracked file, exactly where you left it in the preceding lesson: you took it out of the staging area, you did not delete it. It did not slip into the amended commit with packing.txt.

What this destroys, and what it cannot

The old commit is not edited. Git does not edit commits. A new one is made with different contents, and your branch is moved to point at it. No branch points to the original, although the reflog keeps it recoverable for a while.

That matters in two ways. It is why the commit count does not grow. And it is why this is safe here: nothing is lost that you had not already decided to replace, and even the abandoned commit is still findable for a while, which is the subject of the last lesson in this chapter.

The real limit is not about safety, it is about other people:

Amend only a commit that nobody else has. Once someone else has your commit, replacing it gives them one history and you another, and the two have to be reconciled by hand.

Here the commit is still private, so replacing it is appropriate. The next lesson keeps that private-history condition but changes the task: remove the newest commit from the branch while keeping its work.

Next: take back a private commit without throwing away its file changes.