Amending the last commit safely Jump to heading#

git commit --amend is the most common history rewrite there is: forgot a file, typo in the message, committed with the wrong email. It replaces the last commit with a new one that includes your correction. Used on a commit nobody else has seen, it is harmless and keeps history tidy. Used on a commit that was already pushed and fetched by others, it creates two versions of the same change that will eventually collide. And used carelessly, it can sweep unrelated staged changes into a commit, or silently drop a signature. This page covers the everyday amend operations, the checks to make before amending, and how to get the original back, within squash and fixup strategies.

When to use this approach Jump to heading#

• The last commit is missing a file, has a typo, or has the wrong message or author.
• The commit has not been pushed, or was pushed only to a branch nobody else uses.
• You want to fold a small follow-up into the commit before opening a pull request.
• For commits further back, use editing an old commit in the middle of a branch instead.

Step 1 — Check whether the commit has been pushed Jump to heading#

Amending a pushed commit means force-pushing, which affects anyone who fetched it. Check before amending.

git status -sb | head -1
# ## feature/export...origin/feature/export [ahead 1]   <- not pushed yet: safe
# ## feature/export...origin/feature/export              <- pushed: think first
git branch -r --contains HEAD           # any remote branch containing the commit?

Step 2 — Add a forgotten file or change Jump to heading#

Stage the missing change and amend without editing the message.

git add src/export/schedule.py
git commit --amend --no-edit
git show --stat HEAD                    # the file is now part of the commit

Check what is staged before amending. --amend includes everything in the index, so an unrelated change you staged earlier would be swept into the commit.

git diff --cached --stat                # everything here will be added to the commit

Step 3 — Fix the message or the author Jump to heading#

To change only the message, amend with an empty index. To fix the author — for example after committing with a personal email on a work repository — reset the author to your current configuration.

git commit --amend -m "feat(export): schedule CSV exports per account"
# Fix the author after correcting user.email
git config user.email [email protected]
git commit --amend --no-edit --reset-author
git log -1 --format='%an <%ae> | %cn <%ce>'

To keep a colleague’s authorship but fix a typo in their commit, amend without --reset-author; only the committer field changes to you.

Step 4 — Keep signatures and hooks in the loop Jump to heading#

Amending creates a new commit, so it must be signed again. With commit.gpgSign enabled, that happens automatically; otherwise add -S. Commit hooks run on amend too, which is usually what you want — but --no-verify skips them, and with them any checks your team relies on.

git commit --amend --no-edit -S
git log -1 --format='%G? %GS'           # G: the amended commit is signed

Signature behaviour across rewrites is covered in keeping signatures valid through rebase and squash.

Step 5 — Push, or recover the original Jump to heading#

If the commit was already on your remote branch, push the amended version with a lease, so you do not overwrite anything someone else pushed.

git push --force-with-lease origin feature/export

⚠️ SAFETY WARNING: Never amend and force-push a commit on a shared branch or on main. Everyone who fetched the original now has a commit the server no longer has, and the next person to push or merge reintroduces it beside your amended version. If you need to correct a shared commit, add a new commit on top, or revert it as described in when to use git revert vs git reset.

If the amend went wrong — you swept in the wrong file, or lost a change — the original commit is one reflog step back.

git reflog -3
# a7e1c02 HEAD@{0}: commit (amend): feat(export): schedule CSV exports per account
# 4d2b9f8 HEAD@{1}: commit: feat(export): schedule CSV exports per account
git reset --soft HEAD@{1}               # back to the original commit, amended changes staged

Validation checklist Jump to heading#

• You checked whether the commit was pushed before amending
• git diff --cached was reviewed so nothing unrelated was swept in
• Message-only and author-only amends left the content unchanged
• The amended commit is signed if your gates require signatures
• Amended commits on your own pushed branch were pushed with --force-with-lease
• Shared branches and main were never amended

Frequently Asked Questions Jump to heading#

Does --amend work on merge commits? Jump to heading#

Yes; it replaces the merge commit with a new one that has the same parents. That is how you fix a merge commit’s message or a conflict resolution before pushing.

Why did my amended commit get a new date? Jump to heading#

The committer date always updates. The author date stays unless you use --reset-author or --date. Most tools show the author date, so a message-only amend usually looks unchanged.

Is git commit --fixup better than amend? Jump to heading#

For the last commit, amend is simpler. Fixup commits shine when the correction belongs to an older commit, or when you want reviewers to see the correction before it is folded in.

Related Jump to heading#

• Squash & Fixup Strategies — the parent topic.
• Squashing Without Interactive Rebase — combining more than one commit.
• Recovering Lost Commits with git reflog — the safety net behind step 5.
• Rejecting WIP and Fixup Commits Before Merge — catching unfinished amends and fixups in CI.