Amending the Last Commit

You just committed and immediately noticed a typo in the message, or realized you forgot to include a file, or spotted a mistake in the code you committed. git commit --amend lets you replace the most recent commit with an updated version — same changes (or slightly different ones), new message, new hash.

Amending the commit message

If you only want to fix the message:

git commit --amend

Git opens your editor showing the current commit message. Edit it, save, and close. The commit is replaced with a new one that has the updated message and a new hash.

Or provide the new message directly:

git commit --amend -m "Add viewpoint and gear notes to Pine Ridge"

Amending the commit contents

If you forgot to include a file, or need to make a small code correction:

1. Stage the additional change:

# make the fix or add the forgotten file
git add forgotten-file.txt

2. Amend:

git commit --amend --no-edit

--no-edit reuses the existing commit message without opening the editor. The commit is replaced with one that includes both the original staged content and the new staged content.

What amend actually does

--amend does not modify an existing commit. It creates a new commit with a new hash and discards the old one. The old commit becomes unreachable in normal history — it no longer appears in git log.

This is fine for local commits. It is not fine for commits that have already been pushed to a shared repository.

The golden rule: never amend pushed commits

If you push a commit to GitHub and then amend it, your local history and the remote history have diverged. The old commit still exists on the remote. Pushing the amended commit requires a force push:

git push --force

Force push rewrites the remote’s history, which causes problems for anyone who has already pulled the old commit. They will need to reconcile their local history manually. On team repositories, this is disruptive and often breaks CI.

The rule is simple: amend only commits that exist on your machine and have never been pushed. Once a commit is on a shared remote, use git revert instead (covered in the next lesson).

Checking whether a commit has been pushed

Look at git log --oneline and compare your local main to origin/main:

* c2a1d08 (HEAD -> main) Add viewpoint note         ← local only, safe to amend
* b7e9d03 (origin/main) Add difficulty notes         ← pushed, do not amend

Anything above origin/main in the log is local-only and safe to amend.

Exercise

1. In your git-practice folder, make a commit with a deliberate typo in the message:

echo "Peak: 2,800 ft elevation" >> summit-challenge.txt
git add summit-challenge.txt
git commit -m "Add elevaion note to Summit Chalenge"

2. Amend the message:

git commit --amend -m "Add elevation note to Summit Challenge"

3. Run git log --oneline and confirm the corrected message appears and the old one is gone.

4. Make one more commit, then realize you forgot to stage a file. Stage the forgotten file and amend the commit:

echo "Group size: max 8" >> summit-challenge.txt
git add summit-challenge.txt
git commit --amend --no-edit

5. Run git show HEAD and confirm both changes (the original commit content and the amendment) are present.

Recap

• git commit --amend replaces the most recent commit with a new one — same contents, or with additional staged changes.
• Use --no-edit to keep the existing message.
• Amend creates a new commit hash. The old commit is discarded from local history.
• Never amend a commit that has been pushed to a shared repository. Force-pushing rewrites remote history and breaks collaborators’ copies.
• For reversing pushed commits, use git revert instead.

Next: git revert — the safe way to undo a commit in a shared repository without rewriting history.