Force-push a Git branch with an explicit lease
Publish rewritten history with a scoped force-with-lease check, inspect the expected remote tip, and understand what a lease does not protect.
When a branch intentionally needs rewritten history, use a scoped --force-with-lease push. The lease checks that the remote ref still points to the commit you expect. It does not decide whether your replacement history preserves every change people need.
Inspect the remote before rewriting
For a feature branch you are authorized to rewrite:
git switch feature-x
git fetch origin
git log --oneline --left-right HEAD...origin/feature-x
expected=$(git rev-parse refs/remotes/origin/feature-x)
git branch backup-before-rewrite
Stop if the fetch fails, and inspect any remote work before proceeding. Save uncommitted edits separately; the backup branch only preserves commits. The shell variable records the remote tip you reviewed.
Then perform the intended rewrite, inspect and test its result, and publish only that branch:
git rebase -i HEAD~3
git push --force-with-lease="refs/heads/feature-x:$expected" \
origin HEAD:refs/heads/feature-x
The example rebase requires at least three commits after the selected base. Keep the expected commit value from the reviewed state; do not update it blindly merely to make a rejected push succeed.
What the lease protects
| Option | Check before a non-fast-forward update |
|---|---|
--force |
Does not require the old remote tip to match a reviewed value |
Bare --force-with-lease |
Usually compares with the corresponding local remote-tracking ref |
--force-with-lease=REF:EXPECTED |
Requires that particular remote ref to match the supplied object ID |
A background fetch can update a remote-tracking ref and weaken the protection you expected from the bare form. An explicit expected ID avoids that dependency. Neither form overrides server protections or makes overwriting known remote work harmless.
After a rebase, git log HEAD..origin/feature-x can legitimately show the old versions of your own rewritten commits. It is not supposed to be empty in every correct rewrite.
FAQ
Why was the push rejected?
The lease may be stale, or server permissions, branch rules, or hooks may reject it. Fetch and inspect the new state. Preserve or integrate other work deliberately before deciding on another rewrite.
What about shared branches?
Follow the project's history policy. A revert is usually the appropriate way to undo a change on a shared branch. Even a personal branch may have consumers; coordinate rewrites and help them preserve their own work rather than telling everyone to reset blindly.
Can Git default every forced push to a lease?
There is no push.useForceWithLease setting. Use the option explicitly or a clearly named alias. A lease alias does not change what git push -f means.
See git-push and git-rebase.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan