What happens to the commit hash after you amend a commit?

It changes, since amending creates a brand-new commit object.

It stays the same since only the message changes.

It changes only if you also modify staged files.

Why is amending a commit that others have already pushed and pulled considered risky?

It rewrites history, causing conflicts for anyone who already pulled it.

It silently updates the remote commit for every collaborator.

Amending pushed commits is blocked by Git and always fails.

How do you add a forgotten file to the previous commit without changing its message?

Stage the file, then run `git commit --amend --no-edit`.

Run `git commit --amend --no-edit` without staging anything first.

Create a brand-new commit; amend cannot add files.

What happens if you amend the very first commit in a repository?

Git creates a new root commit replacing the original one.

Git refuses because the first commit can never be amended.

Git merges it into the second commit automatically.

Git Amend

Git amend replaces your most recent commit with a new one, letting you fix a typo'd message or slip in a forgotten file change without cluttering history with a follow-up commit.

What Amend Really Does

git commit --amend does not edit the previous commit in place — it creates an entirely new commit that replaces it, combining whatever is currently staged with the contents of the old commit, and lets you reuse or rewrite its message. Because it's a replacement rather than a true edit, the old commit's hash disappears from your branch and a new hash takes its place. That's the detail that makes amend perfectly safe on unpushed work and risky on anything already shared.

Fixing a Commit Message

The most common use case is realizing your last commit message has a typo or doesn't describe the change well. Running amend with no staged changes and a new -m message swaps in the corrected text while leaving the file changes untouched.

Fix a typo in the last commit message

$ git log --oneline -1
4e8a012 (HEAD -> main) Fix bg in header render

$ git commit --amend -m "Fix bug in header render"
[main 8b1f5c9] Fix bug in header render
 Date: Thu Jul 16 10:22:03 2026 +0530
 1 file changed, 4 insertions(+), 1 deletion(-)

$ git log --oneline -1
8b1f5c9 (HEAD -> main) Fix bug in header render

Adding a Forgotten File to the Last Commit

If you commit and then notice you forgot to stage a file that belonged with that change, stage it and amend without passing a new message — Git will reopen your editor with the old message pre-filled, or you can keep it as-is with --no-edit.

Add a forgotten file, keep the same message

$ git status
On branch main
Untracked files:
  src/utils/formatDate.js

$ git add src/utils/formatDate.js
$ git commit --amend --no-edit
[main 2c9e441] Fix bug in header render
 2 files changed, 15 insertions(+), 1 deletion(-)

Amending Further Back With Rebase

Amend only ever touches the single most recent commit. If the commit you need to fix is two or three commits behind HEAD, plain amend can't reach it — you need an interactive rebase, marking the target commit as 'edit', making your fix, and continuing.

Amend a commit that isn't the most recent one

$ git rebase -i HEAD~3
# mark the target commit's line as 'edit', save and close
Stopped at 6a3f120...  Add pricing table

$ echo 'fixed content' >> src/pricing/table.js
$ git add src/pricing/table.js
$ git commit --amend --no-edit
$ git rebase --continue
Successfully rebased and updated refs/heads/main.

git commit --amend -m "new message" — replace both message and staged changes
git commit --amend --no-edit — replace the commit's contents, keep the same message
git commit --amend --author="Name <email>" — correct the recorded author
git rebase -i HEAD~n then mark 'edit' — amend a commit further back in history
git push --force-with-lease — required to update a remote after amending a pushed commit

Note: Amending changes the commit hash. If you already pushed the original commit and anyone might have pulled it, amending and force-pushing will rewrite their history out from under them. Only amend commits that are still local, or coordinate explicitly with your team first.

Note: If you do need to force-push after an amend, prefer --force-with-lease over a plain --force — it refuses to overwrite the remote if someone else pushed new commits since you last fetched, which prevents silently discarding their work.

Amend vs a Fresh Commit

Scenario	Use amend	Use a new commit instead
Typo in the message you just wrote	Yes	No, adds noise
Forgot one file in the commit you just made	Yes	No, keeps the logical change together
Commit already pushed and pulled by others	Avoid	Yes, safer
Change is logically separate from the last commit	No	Yes, keeps history meaningful

Used well, amend keeps your commit history tidy: one commit per logical change, with an accurate message, instead of a trail of "oops" and "fix previous commit" entries. The tradeoff is that it's a rewriting operation, so the same sharing rule that applies to reset applies here too.

Exercise: Git Amend

What does `git commit --amend` primarily let you modify?

Keep Going

Git Interview QuestionsPractice real questions asked for Git DevOps Engineer SalarySee what DevOps Engineer roles pay in the market Auto Apply for JobsApply to open roles related to Git and tweak your resume