Amend Commit - Fix Last Commit

We have all been there. You just made a commit, felt good about it, and then immediately noticed a typo in the commit message. Or worse, you forgot to include that one critical file. The good news is that Git provides a clean way to fix your most recent commit without creating an awkward "oops, forgot this" follow-up commit.

The git commit --amend command lets you modify the last commit in your history. Think of it as a do-over for your most recent snapshot. Instead of creating a new commit, it replaces the previous one entirely with a new commit that contains your corrections.

Fixing a Commit Message

The most common use case is fixing a typo or improving a poorly worded commit message. Here is how you do it:

When you run the second version without the -m flag, Git opens your configured text editor with the previous commit message pre-filled. You can edit it, save, and close the editor. The commit hash changes because the message is part of the commit's identity.

Adding Forgotten Files

This scenario happens constantly in real development. You committed your work but forgot to include a file:

The --no-edit flag keeps the original commit message unchanged. After this operation, your last commit now includes the forgotten file as if it was always part of the original commit.

Here is a more realistic workflow showing this in action:

Changing the Author Information

Sometimes you commit from a machine where your Git identity is configured differently, or you need to attribute the commit to someone else:

This is particularly useful when pair programming and you want to properly attribute the commit to both contributors, or when you accidentally committed using your personal email on a work project.

Removing Files from the Last Commit

You can also remove files that should not have been included:

The Golden Rule: Never Amend Public Commits

This is critically important and something that trips up beginners constantly. Once you have pushed a commit to a shared remote branch, you should never amend it:

When you amend a commit, Git creates an entirely new commit object with a different hash. If teammates have already pulled the original commit, their history diverges from yours. Force pushing then destroys their reference point, potentially causing lost work and significant confusion.

What Happens Internally

Understanding the mechanics helps you appreciate why amending is safe locally but dangerous publicly:

Git does not actually modify the old commit. It creates a brand new commit with the updated content and moves the branch pointer to it. The old commit becomes orphaned and will eventually be garbage collected after about 90 days.

Amending Versus Interactive Rebase

The --amend flag only works on the most recent commit. If you need to fix an older commit, you need interactive rebase:

Common Mistakes and How to Avoid Them

Mistake 1: Amending when you meant to create a new commit. If you accidentally amend, use git reflog to find the pre-amend state and reset back.

Mistake 2: Amending a merge commit. This can create complications. If you must fix a merge commit message, git commit --amend works, but be cautious with the content.

Mistake 3: Forgetting --no-edit and accidentally changing the message. Always use --no-edit when you only want to add files without touching the message.

Practical Developer Workflow

Here is a typical workflow where amending saves the day:

Interview Questions

Q1: When should you amend versus create a new commit?

Amend when the commit has not been pushed and you are fixing something trivial like a typo, forgotten file, or formatting issue. Create a new commit when the change represents genuinely new work, or when the commit has already been shared with others. The rule is simple: amend for local corrections, new commits for public history.

Q2: What happens internally when you amend a commit?

Git creates an entirely new commit object with a new SHA-1 hash. The old commit still exists in the object database and can be found via git reflog, but no branch points to it anymore. Eventually garbage collection removes unreachable commits after approximately 90 days.

Q3: Can you amend commits other than the most recent one?

Not directly with --amend. You need git rebase -i (interactive rebase) to modify older commits. Mark the target commit as "edit" in the rebase todo list, make your changes, amend, then continue the rebase with git rebase --continue.

Q4: How do you recover if you accidentally amend the wrong commit?

Use git reflog to find the commit hash before the amend operation, then git reset --hard <hash> to restore the original state. The reflog keeps references to previous HEAD positions for approximately 90 days.

Q5: Is it safe to use --amend on a branch that only you work on even if pushed?

Technically yes, with git push --force-with-lease which is safer than --force because it checks that no one else has pushed in the meantime. However, it is still best practice to only amend before pushing whenever possible.