What is --force-with-lease in Git?

If you’ve ever worked on a shared Git branch, you’ve probably run into the dreaded “non-fast-forward” error when trying to push your changes. You might have even been tempted to use --force — but that can be dangerous. That’s where --force-with-lease comes in.
Let’s break it down with a simple example.

Imagine we have one remote branch and two local clones:

Remote:    A -> B
Local_A:   A -> B
Local_B:   A -> B

Both Local_A and Local_B start from the same commit history as the remote.

Scenario 1: Safe push with --force-with-lease

Now, I (working on Local_A) make a new commit:

Local_A:   A -> B -> C

When I push using:

git push --force-with-lease

the command succeeds, because my local branch is still in sync with what’s on the remote.
After the push, the remote gets updated:

Remote:    A -> B -> C
Local_A:   A -> B -> C
Local_B:   A -> B

Everything looks good — I’ve safely updated the remote.

Scenario 2: Someone Else Commits

Now suppose someone else (Local_B) also makes a new commit on their local branch:

Local_B:   A -> B -> D

They try to push with:

git push --force-with-lease

But this time, the push fails.

Why?

Because the remote no longer points to commit B — it was updated to C when Local_A pushed earlier. Git detects that the remote has moved since Local_B last pulled, and refuses to overwrite it.

Why It’s Safer?

This built-in check makes --force-with-lease a safer alternative to --force. It prevents you from accidentally overwriting someone else’s work, which can easily happen when multiple people are collaborating on the same branch.

So, if you ever need to rewrite history or rebase on a shared branch, make sure to use:

git push --force-with-lease

It’s your safety net against losing someone else’s commits — and keeps teamwork smooth.