We’ve all been there. You just made a commit, hit Enter, and then… “Wait, I forgot a file!” or “That message is completely wrong!”

Don’t worry. Git has you covered. In this article, we’ll explore two powerful (but sometimes scary) tools:

• git commit --amend --no-edit ? Fix your last commit without changing its message
• git push --force-with-lease ? Safely push a rewritten commit to the server

git commit --amend --no-edit

This command lets you modify your last commit by adding forgotten files or fixing small mistakes — without changing the commit message.

Think of it like editing the last page of your notebook before handing it in, without rewriting the title.

Real-life Example

Imagine you’re working on a website. You commit your changes:

git add homepage.html
git commit -m "Add homepage layout"

Then you realize: “Oh no, I forgot to include the CSS file!”

Without --amend, you’d have to create a new commit just for one forgotten file. Messy! Instead:

# Step 1: Stage the forgotten file
git add style.css

# Step 2: Add it to the last commit, keeping the same message
git commit --amend --no-edit

Result: Your last commit now includes bothhomepage.htmlandstyle.css, still named “Add homepage layout”. Clean and tidy!

 Another Example: Fixing a Typo in a File

You committed a file with a small typo in the code:

git commit -m "Fix navigation bar bug"
# Oops! You left a typo in navbar.js

Fix the typo, then:

git add navbar.js
git commit --amend --no-edit

The commit is updated with the fix. No extra “oops” commit in your history. Your history stays clean and professional.

Important Warning

When you use --amend, Git rewrites the commit. It’s not editing it in place — it creates a brand new commit with a new internal ID, and discards the old one.

Before amend:  ... -> [abc1234] "Add homepage layout"
After amend:   ... -> [xyz9999] "Add homepage layout"  <- new ID!

This is totally fine if you haven’t shared the commit yet (i.e., not pushed to a remote server).
But if you already pushed it, you’ll need a special push command. More on that below!

Amend Variants — Quick Comparison

git push --force-with-lease

The Problem: Why Can’t I Just Push Normally?

After using --amend, if you try a regular git push, Git will refuse:

git push
#  Error: Updates were rejected because the tip of your current branch is behind its remote counterpart.

Why? Because Git sees that your local history diverges from what’s on the server. The server has the old commit (abc1234), but you now have a new one (xyz9999).

You need to tell Git: “I know what I’m doing, please overwrite the remote with my version.”
That’s what force push is for.

The 3 Force Push Options Explained

Option 1: git push --force (or -f)

The nuclear option. It overwrites everything on the server, no questions asked.

git push --force

The danger:

Server:     A -> B -> C   <- your colleague just pushed C
You local:  A -> B -> D   <- your amended commit

git push --force -> C is GONE forever. Your colleague loses their work.

Never use --force on a shared branch. It can permanently destroy your teammates’ work.

Option 2: git push --force-with-lease (recommended)

The safe force push. Before overwriting, it checks:

“Has anyone else pushed to this branch since I last synced?”

If yes -> Push is refused. You’re protected.
If no -> Push goes through safely.

git push --force-with-lease

Visual example:

Scenario A — Safe:
Server:    A -> B        <- nobody pushed after you
You local: A -> B -> D   <- your amended commit
Result:  Push accepted!

Scenario B — Protected:
Server:    A -> B -> C   <- colleague pushed C
You local: A -> B -> D   <- your amended commit
Result:  Push refused! Go check what C is first.

Option 3: git push --force-with-lease --force-if-includes (maximum safety)

This is the most secure option. It adds an extra check on top of --force-with-lease:

“Not only must the remote not have changed, but I must have actually integrated those remote commits into my local history.”

It closes a subtle loophole: if you ran git fetch recently, --force-with-lease alone might still allow an accidental overwrite. --force-if-includes prevents that.

git push --force-with-lease --force-if-includes

Summary Table: Which Force Push to Use?

Command	Safety	When to use
git push --force	Dangerous	Almost never
git push --force-with-lease	Safe	After amend/rebase on your own branch
git push --force-with-lease --force-if-includes	Safest	When you want maximum protection

Key Takeaways

• git commit --amend --no-edit ? Add forgotten files to your last commit, keeping the same message
• --amend rewrites history ? The commit gets a new ID
• Never use git push --force on shared branches ? You risk destroying teammates’ work
• git push --force-with-lease ? The safe way to push a rewritten commit
• Add --force-if-includes for maximum safety