How to Force Push Safely Using Git Force With Lease

Rebase or amend a commit that has already been pushed, and Git may reject your next push because the remote branch history no longer matches yours. A force push can update that history, but a blind overwrite can discard someone else's commits. Learn what --force-with-lease checks, how to use it, and what to do before rewriting a shared branch.

What does git push --force-with-lease do?

A normal git push updates a remote branch only when the update can be applied without discarding commits. Rewriting local history with commands such as git rebase or git commit --amend can make that update non-fast-forward, so Git refuses it.

git push --force overrides that protection. In contrast, git push --force-with-leasenormally checks that the remote branch is still at the commit your local remote-tracking ref expects. If someone has pushed new work since your last fetch, the lease should fail instead of overwriting that unexpected update. It's a useful guard, not a substitute for checking the branch and coordinating with collaborators.

Before you force push: check the branch and remote

Confirm you are on the intended branch and know which remote you will update. A mistaken branch name or remote can have a much wider impact than the history rewrite you intended.

git status
git branch --show-current
git remote -v
git log --oneline --decorate --graph -10

Make sure your intended commits are present, the working tree is in a state you understand, and your branch tracks the expected remote branch. If the branch is shared, tell collaborators before rewriting it. Prefer a normal push whenever you do not need to replace remote history.

Fetch, inspect, then force push with a lease

1. Fetch the latest remote information: git fetch origin. Replace origin if your remote has a different name.
2. Inspect the remote branch and compare it with your local branch. For example, use git log --oneline --left-right HEAD...origin/feature to review commits unique to each side. Replace feature with the branch you intend to update.
3. If the remote has commits you do not have, stop and integrate or preserve them before pushing. Do not treat a rejected lease as an obstacle to bypass.
4. When you have verified the rewrite is intended, push the specific branch: git push --force-with-lease origin feature.

The remote and branch names are examples. Always substitute the correct values for your repository. Specifying both makes the destination explicit and reduces the chance of updating a different branch than you meant to.

Why a force-with-lease push can still be risky

The default lease is based on your locally recorded view of the remote branch. If you fetch after another person pushes, that remote-tracking ref advances; depending on your next steps, the default lease can then accept a rewrite that replaces commits you have not incorporated. A fetch is valuable because it reveals new work, but it does not automatically merge or preserve it.

Review the commits after fetching, and coordinate before replacing work on a shared branch. For extra protection, you can provide the exact remote commit you expect to replace with an explicit lease:

git fetch origin
git rev-parse refs/remotes/origin/feature
git push --force-with-lease=refs/heads/feature:<expected-commit> origin feature

Replace <expected-commit> with the exact commit ID you recorded and reviewed. Git refuses the push if the remote branch no longer matches that value. If you fetch again and simply copy the new value without reviewing what changed, you remove much of this additional protection. Branch protections and server-side rules may also block force pushes, as they should for many important branches.

What to do when the lease rejects your push

A rejected lease is a warning that the remote does not match the expected state. Fetch and inspect the changed commits; do not immediately retry with --force. If a teammate's work is on the remote, communicate and decide whether to rebase your branch onto it, merge it, or use another agreed workflow. Then test the resulting history and retry only if replacing the remote history is still necessary.

A force push changes the branch pointer; it does not erase every copy of the old commits instantly. A teammate may be able to recover a displaced commit from a local branch or reflog. If work seems missing, ask collaborators to stop pushing to the branch while you investigate rather than repeatedly rewriting it.

Git force-with-lease FAQ

Is --force-with-lease always safe?

No. It helps prevent overwriting remote changes that do not match your expected state, but it cannot decide whether a rewrite is appropriate or whether you have preserved all teammates' work. Verify the branch, inspect commits, and coordinate on shared branches.

Should I use --force-with-lease instead of --force?

If a history rewrite is necessary and your team allows it, prefer --force-with-lease to a blind --force. Use a regular push when history does not need to be rewritten.