What happens when I amend the most recent Git commit?
Quick answer
Amending replaces the current branch’s latest commit with a new commit, rather than editing the old one in place. The replacement gets a different identifier because it is a new commit object. Before amending, review the staged changes: the replacement records the current staging area. If the original commit has been pushed or shared, a new commit is the safer default unless a history rewrite has been coordinated. [S1] [S2] [S3]
The question, the details, the next step.
I made the latest commit, then noticed I forgot a small change. What does git commit --amend actually do?
It replaces the current branch tip with a newly created commit; it does not alter the original commit object. The replacement normally has the same parent as the original latest commit, so it takes that commit’s place in the branch history. [S1] [S2]
For example, suppose your local history ends with A — B, where B is the latest commit. After amending, the branch points to a new commit, say B′, giving A — B′. The original B has not been edited; the branch now points to the replacement instead. This can be appropriate for correcting the latest local commit, such as adding an omitted change or improving its message.
Why does the commit ID change if I’m only fixing the message?
A commit ID is a cryptographic hash of the commit object. That object includes its tree, parent or parents, author and committer details and times, and message. Since amending creates a new object, its ID reflects the replacement object—even if the change seems minor. [S2]
The old object remains unchanged, but your branch no longer points to it after the amendment. So don’t treat the old and new IDs as interchangeable when referring to the commit. If you want to keep the existing message while changing the recorded content, Git documents --no-edit for retaining that message. [S1]
What should I check before running it? I have one fix ready, but I’m not sure what else I staged.
Review the staging area first. The replacement commit is prepared from the current index, so staged changes are candidates for inclusion—not just the fix you had in mind. [S1] [S3]
Ask yourself: does everything staged belong in this replacement? If yes, proceed. If not, adjust what is staged and review it again before amending. For example, if your intended fix is staged alongside an unrelated change, pause and decide whether both belong in the same commit. The key check is whether the staged content is exactly what you want the replacement to record. [S1]
I already pushed the commit. Is amending still a good idea, or should I use a new commit?
If the commit has already been pushed or shared, a new commit is the safer default. Amending replaces the branch tip and rewrites history, while other people may still rely on the original commit. Git’s documentation advises against amending a commit that has already been pushed for this reason. [S1] [S3]
Amend when the latest commit is still local and you intend to replace it. If it is shared, choose a new commit unless a history rewrite has been coordinated with everyone relying on that branch. When uncertain, check your team’s agreed workflow before changing shared history.
A practical checklist
Confirm the commit you intend to replace is the latest commit on your branch.
Check whether that commit has been pushed or otherwise shared.
Review the staged changes before amending.
Make sure the staged content is what you want recorded in the replacement.
Decide whether to change the message or keep it with
--no-edit.
A few more useful answers
Does amending change the old commit object?
No. Amending creates a new commit object; the old object remains unchanged, although your branch points to the replacement. [S2]
Can I amend just to change the commit message?
Yes. Amending creates a replacement commit. Review the staged content first; use --no-edit if you want to keep the existing message. [S1]
What if I’m unsure whether the commit was shared?
Pause and check with the relevant collaborators before rewriting history. If it is shared, a new commit is the safer default. [S3]
Sources
References used for this guide.
- [S1] Git commit command reference: amend behavior and staged content git-scm.com · Checked
- [S2] Git data model: commit objects, IDs, and amending git-scm.com · Checked
- [S3] Pro Git: changing the most recent commit and rewriting shared history git-scm.com · Checked