How can git push --force-with-lease still overwrite a teammate's commits?

## The gap in one paragraph `--force-with-lease` compares the remote ref against your remote-tracking ref. It is checking *freshness of information*, not *whether you did anything about it*. Those come apart the moment something other than a deliberate `git fetch` updates your tracking refs — and on a modern developer machine, several things do. ## How the accident happens 1. You fetch, then start an interactive rebase of `feature/api` and leave it half-done. 2. A teammate pushes a hotfix commit to the same branch. 3. Your editor's periodic fetch, or a `git fetch --all` from a script, updates `refs/remotes/origin/feature/api` to include that commit. 4. You finish the rebase and run `git push --force-with-lease`. 5. The lease compares the remote ref to your tracking ref. They match — the tracking ref was refreshed for you. The push is accepted. 6. The teammate's commit is no longer reachable from the branch. Nothing warned you, because from the lease's point of view your information was current. The information was current; your *branch* was not. ## What --force-if-includes checks instead `--force-if-includes` was added in Git 2.30 and is meaningful only in combination with `--force-with-lease`. Rather than comparing ref values, it asks whether the commit the remote-tracking ref points at has actually been incorporated into the local branch you are pushing — determined by checking whether that commit is reachable from an entry in the local branch's reflog. The distinction is exactly the one that matters: a fetch updates a remote-tracking ref but leaves no trace in your branch's reflog, so it does not satisfy the check. Rebasing your branch onto the fetched tip, or merging it in, does. In effect the flag says "force only if my branch was built on top of what the remote currently has". Because it is meaningful only with a lease, request both explicitly rather than relying on defaults: `git push --force-with-lease --force-if-includes origin feature/api` ## The other robust answer Pin the expectation yourself: `git push --force-with-lease=feature/api:<sha> origin feature/api`, where `<sha>` is the remote tip you personally inspected. Nothing that happens to your tracking refs can change a value you typed. This is verbose but bulletproof, and it is the right form inside automation, where background fetches are common and a wrong force-push is expensive. ## What none of it fixes All three variants only decide whether *this* push should be accepted. None of them helps the people who already fetched the pre-rewrite branch: their local branches still descend from commits that no longer exist upstream, and they must reset or rebase onto the new tip rather than merge. And none of them is a substitute for enforcement — a client-side flag is a courtesy, so branches that must never be rewritten should be protected at the receiving repository, where no client flag can bypass the rule. ## Demonstrating it in an interview The answer that lands is the mechanism, not the flag name: "the lease is a check on my *information*, and information can be refreshed without me. `--force-if-includes` checks my *branch* instead — whether what the remote has was actually integrated into what I am about to push — and an explicit expected value achieves the same thing by taking the tracking ref out of the loop."