Git amend: change the last commit safely
These blocks describe different cases, not one script. Choose the case that matches your repository. Replace example branch names, file paths and VERIFIED_COMMIT before use. Abort commands apply only to their active operation; do not run both alternatives.
Short answer
git commit --amend replaces the current tip with a new commit; it does not edit the original object in place. Use it to fix a local last commit's message or contents after inspecting what is staged. For a commit already shared with others, an additional corrective commit is usually easier to coordinate than rewriting their history.
The example and its prerequisites
This example uses one ordinary local commit with a misspelled message and an omitted change to src/parser.js. These are two separate repairs: message only, or contents as well. The example is not for an earlier commit, a root commit, or a merge needing special review. Start with the current tip and replace the file name and message with those from your repository.
Inspect before changing anything
Inspect git status, the last commit and git diff --cached. The index supplies the content for an ordinary commit --amend, so unrelated staged files can enter the replacement unexpectedly. Inspect unstaged changes as well to understand what remains outside it. Confirm whether the old commit was pushed, merged or used by another person before deciding to change its identity.
git status --short
git log -1 --oneline
git diff --cached
git diffKeep a reference or a separate checkout
Create rescue/before-amend at HEAD before replacing the tip. This retains the original committed object for comparison; it does not save every working-tree edit. Save valuable local files separately when required. Reflog may also help identify old reference states while retained locally, but it is not a promise of permanent object retention or a backup of never-committed edits.
git branch rescue/before-amend HEADThe first workflow
For a message-only repair, --amend --only without paths leaves already staged changes out of the replacement. The -m example supplies the corrected message. Inspect the new commit and the index afterwards: the staged work should still be available for its separate commit. If you intend to include staged contents too, that is the other workflow; do not select it just because both commands contain --amend.
git commit --amend --only -m "Fix parser error message"
git diff --cachedChoose the other outcome deliberately
For a missing-file repair, stage only the intended path, inspect the complete staged diff, then use --amend --no-edit to retain the existing message. Other staged files are still included unless you exclude them deliberately. Run the project's relevant checks first. Splitting a file into reviewed hunks can help, but choosing part of a file does not itself prove the final combined commit is correct.
git add -- src/parser.js
git diff --cached
git commit --amend --no-editLimits and exceptions
If the tip was already shared, prefer a new correction commit on top of it. A rewritten tip may require a coordinated history rewrite to publish, and protected branches may prohibit it. This guide deliberately does not supply a generic force-push command. If a team explicitly permits a rewrite, follow its agreed lease, branch and collaborator checks in that separate procedure.
git add -- src/parser.js
git diff --cached
git commit -m "Correct parser handling"Conflicts and cleanup
Amending the current tip usually has no conflict-resolution sequence of its own. Hook failures or a rejected commit are reasons to inspect the message and status, not to use reset --hard automatically. If you amended the wrong contents, compare the replacement with rescue/before-amend first. Keep uncommitted files out of any corrective reset decision unless their copies have been verified.
Verify the result
Compare the old and new commit's files and message. Their IDs should differ; that is normal. For a message-only repair, their trees should match. For a contents repair, only the intended patch should differ. Check status for staged work left behind and retain the rescue reference until the reviewed replacement is safely part of your intended history.
git show --stat HEAD
git diff rescue/before-amend HEAD
git status --shortCommon questions
Does --no-edit prevent content changes? No, it keeps the message; staged contents can still change the commit. Can amend fix an older commit? Not directly; that requires a different history-editing workflow. Should I amend after pushing? Only with an explicit shared-history policy; an additional correction avoids many coordination problems.
Review the operation in FluxGit
Use FluxGit’s visual history and patch view to review the operation and the relevant commits. Keep the branch, sharing and local-file checks in this example. The download page lists the currently available builds and platforms.