Fixing the Last Commit with git commit --amend

Sometimes you create a commit and immediately notice a small mistake:

You typed an unclear commit message.
You forgot to stage one of the files.
You included the main change but missed a small related correction.

If the commit is the latest commit, belongs to you, and has not been pushed to a remote repository, you can usually correct it with:

git commit --amend

--amend means: create a replacement for the most recent commit. It does not edit the existing commit in place. Git creates a new commit, gives it a new commit ID, and moves the current branch and HEAD to that replacement commit.

The safe rule

Use git commit --amend when all of the following are true:

You are correcting the latest commit.
The commit is your own work.
You have not pushed it to a remote repository.
Other people have not based their work on it.

Amend private local history. Do not amend shared history.

If the commit has already been pushed or another person may have pulled it, create a new corrective commit instead.

Important: commits are local until you push them

Creating a commit does not automatically upload it to GitHub, GitLab, or another server.

git commit -m "feat: add login validation"

This records the commit in the local repository. The commit is uploaded to a remote repository only when a command such as the following is used:

git push

Amending is therefore normally safe before the original commit has been pushed or shared.

Case 1: Correct the latest commit message

Imagine that you created this commit:

git commit -m "update file"

The message is too vague. You want to replace it with a clearer message:

git commit --amend -m "fix: reject an empty password during login"

This creates a replacement commit using the new message:

Before:

a1b2c3d  update file
   ↑
 HEAD

After:

e4f5g6h  fix: reject an empty password during login
   ↑
 HEAD

e4f5g6h is a new commit ID. Git did not rename or edit commit a1b2c3d in place.

Before changing only the commit message, check the current state:

git status

If staged changes appear, do not continue until you understand whether they should be included.

Case 2: Add a forgotten file without changing the message

Suppose the latest commit added the login feature, but you forgot to include a related change in auth.js.

First, inspect the state:

git status

Stage the forgotten file:

git add auth.js

Inspect exactly what is staged:

git diff --staged

Then add the staged content to the replacement commit while preserving the previous commit message:

git commit --amend --no-edit

git add auth.js
    Stages the current content of auth.js.

git diff --staged
    Shows the line-by-line changes prepared for the next commit.

git commit --amend --no-edit
    Creates a replacement for the latest commit using the current
    staged snapshot while keeping the previous commit message.

--no-edit means “keep the existing commit message.” It does not mean that the commit content cannot change.

What gets included?

git commit --amend uses the current Staging Area when creating the replacement commit.

File state	Included by `git commit --amend`?
Staged change	Yes
Unstaged change	No
Untracked file that was not added	No
Unchanged tracked file already present in the latest snapshot	Remains part of the snapshot

Files do not physically move between the Working Tree, Staging Area, and Repository — Git compares and records different versions or states of their content.

Recommended inspection sequence:

git status
git diff --staged
git commit --amend --no-edit

git status        → Which files are staged, unstaged, or untracked?
git diff --staged → What exact staged lines will be recorded?

Why does the commit hash change?

A commit ID identifies a complete commit object. A commit contains or references information including:

The project snapshot through a tree.
The parent commit.
The author and committer information.
Timestamps.
The commit message.

Amending creates a new commit object. Changing the message, the staged snapshot, or relevant commit metadata results in a new commit ID.

Old commit:

a1b2c3d
├── tree: T1
├── parent: P1
└── message: "update file"

Amended replacement:

e4f5g6h
├── tree: T1
├── parent: P1
└── message: "fix: reject an empty password during login"

Even though the project snapshot and parent may remain the same in a message-only correction, the message is different, so the commit object and its ID are different.

For the forgotten-file case:

Old commit:

a1b2c3d → tree T1

Amended replacement:

k7m8n9p → tree T2

The replacement has a different snapshot and therefore a different commit ID.

A commit hash identifies the entire commit, not only its files.

What happens to `HEAD` and the branch?

Before amending:

main
HEAD
  ↓
a1b2c3d

After amending:

main
HEAD
  ↓
e4f5g6h

The current branch and HEAD now point to the replacement commit.

The old commit is not immediately erased forever:

It is no longer the latest commit referenced by the current branch.
Git may retain it temporarily.
It may be recoverable for some time through mechanisms such as git reflog.
Detailed recovery with reflog is outside the scope of this lesson.

Verify the result

After amending, inspect the latest commits:

git log --oneline -n 2

The newest line should show the corrected commit message and a new abbreviated hash.

Also inspect the repository state:

git status

If everything has been committed and no additional edits exist, Git should report a clean Working Tree.

When not to amend

Do not normally amend a commit when:

It has already been pushed.
Another person may have pulled it.
A teammate has based new commits on it.
It is not the latest commit.

Amending a shared commit rewrites history. Your local branch and the remote branch would then contain commits with different IDs:

Remote history:

A ── B

Local history after amending B:

A ── B'

B and B' are different commits, even if their changes look similar.

Fixing the remote branch would require a force-push operation, which is outside the scope of this beginner lesson. Instead, create a new corrective commit:

git add auth.js
git commit -m "fix: add missing login validation"
git push

Latest private local commit
→ Amend is usually appropriate.

Pushed or shared commit
→ Create a new corrective commit.

Limit: only the latest commit

git commit --amend replaces only the latest commit referenced by HEAD. It is not used to directly edit an arbitrary older commit. Editing older commits requires other history-rewriting tools, which are outside the scope of this lesson.

Command summary

Goal	Command
Change the latest commit message	`git commit --amend -m "new message"`
Open the editor to revise the latest message	`git commit --amend`
Add staged changes and keep the existing message	`git commit --amend --no-edit`
Inspect the repository state first	`git status`
Inspect the exact staged changes first	`git diff --staged`
Verify the latest commits	`git log --oneline -n 2`

Common mistakes

Amending with unrelated staged changes

If another file is already staged, it may be included in the replacement commit. Always check:

git status
git diff --staged

Assuming `--no-edit` prevents content changes

--no-edit only preserves the previous commit message. Staged content can still change the replacement commit.

Amending a pushed commit

This changes the commit ID and creates different local and remote histories. Beginners should normally make a new commit instead.

Trying to amend an older commit

git commit --amend works with the latest commit only.

Key takeaway

git commit --amend does not repair the latest commit in place. It uses the current Staging Area to create a replacement commit, assigns it a new hash, and moves the current branch and HEAD to it.