Chapter 2.2 — Fix Last Commit — amend --no-edit☕ 14 min read

Fix Last Commit — amend --no-edit

amend --no-edit se last commit mein changes add karo bina message badle. Lekin yaad rakhna: push kiye hue commit ko KABHI amend mat karna!

01What is amend --no-edit?

git commit --amend --no-edit is the simplest Git fix command. It takes whatever is currently in your staging area and merges it into the last commit — without changing the commit message.

Think of it this way: you just committed, realized something small is missing, and want to slip it into the same commit. That is exactly what --amend --no-edit does.

Common scenarios:

Forgot to stage a file — you committed but left out requirements.txt. Stage it, then amend.
Quick typo fix — noticed a typo right after committing. Fix it, stage it, then amend.
Build failure — CI failed because of a missing semicolon. Fix and amend.

The --no-edit flag is crucial: it tells Git to keep the existing commit message exactly as it is. Without it, Git would open your editor to let you change the message.

Without --amend, every typo fix would need a separate "oops" commit, cluttering your history with noise.

# You committed but forgot a file
echo "main code" > app.js
git add app.js
git commit -m "feat: add app logic"

# Oops! Forgot requirements.txt
echo "flask" > requirements.txt
git add requirements.txt

# Add it to the last commit without changing the message
git commit --amend --no-edit

# Now the last commit includes BOTH app.js and requirements.txt
git show --stat
# app.js            | 1 +
# requirements.txt  | 1 +

The --no-edit flag is what makes this command surgical. Without it, Git opens your default editor to change the commit message. With --no-edit, the message stays untouched — only the content of the commit changes. This is why it is the safest form of amend for "I just forgot one file" situations.

02How amend Creates a New Commit

The most important thing to understand about --amend: it does NOT edit the existing commit. It creates a brand new commit object with a new SHA hash.

Git commits are immutable. You can never change a commit — you can only create a new one that replaces it. This is a fundamental Git principle.

When you run git commit --amend --no-edit, Git does this:

Takes the tree (file snapshot) from the last commit
Merges in your staged changes to create a new tree
Keeps the same commit message and author info
Creates a NEW commit object with a NEW SHA hash
Moves your branch pointer to the new commit

The old commit still exists in Git's object store but becomes orphaned — no branch or tag points to it anymore. You can still find it via git reflog.

Because the SHA changes, this is why amending a pushed commit causes problems — your local history diverges from the remote.

# Check the hash before amend
git log --oneline -1
# a1b2c3d feat: add app logic

# Make a change and amend
echo "new line" >> app.js
git add app.js
git commit --amend --no-edit

# The hash changed!
git log --oneline -1
# d4e5f6g feat: add app logic   ← DIFFERENT HASH!

# The old commit is still accessible via reflog
git reflog | head -2
# d4e5f6g HEAD@{0}: commit (amend): feat: add app logic
# a1b2c3d HEAD@{1}: commit: feat: add app logic

💡 Pro Tip: You can see both the old and new commits using git reflog. The old commit (a1b2c3d) is still there — it is just not reachable from any branch. Git will eventually garbage collect it after about 90 days. Until then, you can always recover it.

03Real-World Scenarios

amend --no-edit is perfect for small fixes that logically belong to the last commit. Here are the real-world scenarios:

Scenario 1: Forgot to save a file before committing. You hit commit, then realize your editor had unsaved changes. Save the file, stage it, amend.

Scenario 2: CI failed on a linting error. Your push triggered CI, and it failed because of a missing semicolon. Fix the error, stage, amend, push again.

Scenario 3: Accidentally committed debug code. You left a console.log or print statement in. Remove it, stage the fix, amend.

The key constraint for ALL these scenarios: the commit must be LOCAL and UNPUSHED. If nobody else has seen the commit, amending it is perfectly safe.

If you are working on a feature branch that only you use, you can amend even after pushing — but you will need git push --force-with-lease to update the remote.

# Scenario 1: Forgot to save the file before committing
git commit -m "feat: user authentication"
# Wait, I forgot to save auth.js in my editor!
# Save the file, then:
git add auth.js
git commit --amend --no-edit

# Scenario 2: CI failed on a linting error
# Fix the linting error in app.js
git add app.js
git commit --amend --no-edit
git push  # (if you have push access and it is your feature branch)

# Scenario 3: Added debug code by mistake
# Remove the debug code
git add app.js
git commit --amend --no-edit

04The Danger — Amending Pushed Commits

If a commit has been pushed to a shared remote, amending it is DANGEROUS.

Because amend creates a new SHA, your local history now diverges from the remote. The remote has commit a1b2c3d, but your local has d4e5f6g in its place. They have the same message but different hashes.

Pushing an amended commit requires git push --force, which overwrites the remote history. If a teammate already pulled the original commit, they now have divergent history.

The consequences:

Duplicate commits — Git sees the old and new commits as different, even though they look similar.
Merge conflicts — teammates will get conflicts when they try to merge or rebase.
Lost work — if someone force-pushed before your teammate pushed, their work could be lost.
Team confusion — nobody knows which version is correct.

The ONLY exception: amending a commit on a feature branch that only you are using. Even then, use --force-with-lease instead of --force.

# DANGEROUS: Amending a pushed commit
git push origin main           # shared with team
echo "fix" >> app.js
git add app.js
git commit --amend --no-edit   # history changed!
git push origin main
# ERROR: Updates were rejected because the tip of your
# current branch is behind its remote counterpart.

# Forcing it (DO NOT DO THIS ON SHARED BRANCHES)
git push --force origin main
# You just overwrote remote history!
# Teammates who pulled the old commit will have conflicts.

# SAFE: Amending your own local feature branch
git checkout -b my-feature
git commit -m "WIP: feature"
git push -u origin my-feature  # only you use this
# Fix something
git add .
git commit --amend --no-edit
git push --force-with-lease origin my-feature  # safer force push

The difference between --force and --force-with-lease: --force blindly overwrites the remote. --force-with-lease checks if someone else pushed to the remote since your last pull — if they did, the push is rejected. Always use --force-with-lease when you must force push. But on shared branches like main, do not force push at all.

05When to Amend vs When to New Commit

Not every mistake deserves an amend. Sometimes a new commit is the right choice.

Use amend when:

The fix is trivial (typo, missing file, lint error) and belongs to the last commit logically.
The commit is local and unpushed.
You want clean history without "fix typo" noise commits.

Use a new commit when:

The fix is a separate logical change (adding logout is not the same as adding login).
The original commit was made long ago — amending only works on the LAST commit.
The commit has already been pushed to a shared branch.

If you need to change the commit message too, use git commit --amend -m "new message" (covered in Chapter 2.3). If you need to add changes to a commit that is not the latest, you need interactive rebase (covered in Stage 5).

And do not use amend as a substitute for proper staging. git add -p lets you stage specific hunks — use it to craft clean commits in the first place.

# GOOD USE OF AMEND: trivial fix belonging to last commit
git commit -m "feat: add login form"
# Oops, forgot the closing tag
# Fix it...
git add login.html
git commit --amend --no-edit

# BAD USE OF AMEND: separate logical change
git commit -m "feat: add login form"
# Now I want to add logout too... this is a separate feature!
# Do not amend. Make a new commit:
git add logout.html
git commit -m "feat: add logout functionality"

# BAD USE OF AMEND: the commit is already pushed
# Use a new commit instead
git commit -m "fix: missing semicolon in login"
git push

💡 Rule of Thumb: If the change you want to add would make someone say "this should have been part of the previous commit", use amend. If they would say "this is a new thing", make a new commit. Clean history is about logical grouping, not about hiding mistakes.

Lo kar liya — Key Points:

✅ git commit --amend --no-edit adds staged changes to the last commit without changing the message
✅ amend creates a NEW commit with a NEW SHA hash — the old commit becomes orphaned
✅ Only use amend on LOCAL, UNPUSHED commits — amending pushed commits causes history divergence
✅ Common use case: forgot to stage a file or need to fix a trivial typo right after committing
✅ If the commit is already pushed to a shared branch, create a new fix commit instead
✅ git push --force is required after amending a pushed commit, which is dangerous on shared branches

Previous2.1 — git reflog — Time Machine 📋 All Chapters Next Chapter2.3 — Fix Commit Message — amend rewrite →