Amending Commits

In one line

git commit --amend replaces your most recent commit entirely — fixing a typo'd message or adding a forgotten file without cluttering history with a separate 'oops' commit.

0/4 · 0%

Think of it like this

Correcting a typo in a letter before sealing the envelope, versus mailing a second letter that just says 'ignore my last letter, here's the fix.' git commit --amend is the first option — it replaces your most recent commit entirely, as if you'd written it correctly the first time.

Key ideas

01
git commit --amend takes whatever is currently STAGED (plus your last commit's original changes) and combines them into a replacement for the previous commit — genuinely useful for 'I forgot to include one file' or 'I need to fix a typo in the message,' rather than creating an awkward, separate follow-up commit just to patch a tiny mistake.
02
git commit --amend --no-edit amends the commit's CONTENT (adding whatever's newly staged) while keeping the existing message completely unchanged — useful when you just forgot a file and the original message is still accurate. git commit --amend -m "new message" replaces just the message, keeping the same content.
03
Amending is, technically, a form of rewriting history (Phase 2.3's rebase discussion) — it replaces the previous commit with a brand-new one that has a different SHA. The exact same golden rule applies: only amend a commit that hasn't been pushed and shared yet. Amending a commit others have already pulled creates the identical divergence problem as rebasing shared commits.
04
A genuinely common real workflow: commit, then immediately notice a forgotten file or a typo BEFORE pushing — git add <the-forgotten-file> followed by git commit --amend --no-edit fixes it cleanly, leaving history exactly as clean as if you'd gotten it right the first time, with zero trace of the mistake.
05
If you've ALREADY pushed a commit and then need to fix it, amending followed by a normal push will be REJECTED (since the amended commit has a different SHA than what the remote has) — this is one of the few legitimate cases for a force-push, covered fully in Topic 5.4, and only ever safe under the exact conditions that topic explains.

Code & diagrams

amending-commits.shmarkdown

Both common amend scenarios — a forgotten file, and a typo'd message.

cd ~/scratch/my-first-repo

# Scenario 1: forgot to stage a file
echo "fix" >> app.txt
git add app.txt
git commit -m "Fix the bug"

echo "forgotten test" >> app_test.txt
git add app_test.txt
git commit --amend --no-edit
# app_test.txt is now part of the SAME commit as the fix — check with:
git show --stat HEAD

# Scenario 2: typo in the message
git commit --amend -m "Fix the calculation bug in totals"
git log -1
# message is corrected, content unchanged

# The golden rule in action — this is safe ONLY because nothing was pushed yet
git log -1 --format="%H"
# note the SHA — it's different from either original commit's SHA

Explain it without notes

Why does git commit --amend produce a brand-new SHA, even when you're only fixing the commit's message?

You already pushed a commit, then amended it locally to fix a typo. What happens when you try to push again with a plain git push?

Practice

Make a commit, forget to stage a second file on purpose, then use git commit --amend --no-edit to fold it in — confirm with git show --stat that both files are now part of the one commit.

Make a commit with a deliberately bad message, then amend just the message with -m, and confirm with git log that the content is unchanged but the message and SHA are both different.

Trade-offs

↔
Amending keeps history clean by avoiding tiny 'oops' follow-up commits, but it's easy to reach for out of habit on a commit you're not actually sure is still unpushed — running git status (which shows if your branch is ahead of its remote tracking branch) or git log before amending is a cheap way to confirm you're not about to rewrite something already shared.

Done when you can

I can use git commit --amend to fix a forgotten file or a typo'd message.
I understand amend produces a new SHA and is subject to the same golden rule as rebase.
I know a plain push fails after amending an already-pushed commit, and why.