If you're always using --force-with-lease as-is instead of --force and looking for some quick info, start using --force-with-lease --force-with-includes instead as it is marginally safer.
If I can have your attention for a little longer then read on. If you git fetch before git push --force-with-lease you are essentially just force pushing with no safety. Adding --force-if-includes will use the reflog in addition to the remote tracking branch to help protect against this sort of thing because performing a fetch seems pretty innocuous and might even happen in the back ground.
From the docs, bold italics on my commentary, bold on the emphasis.
--[no-]force-with-lease--force-with-lease=<refname>--force-with-lease=<refname>:<expect>Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.
This option overrides this restriction if the current value of the remote ref is the expected value. "git push" fails otherwise.
[...]
Alternatively, specifying
--force-if-includesas an ancillary option along with--force-with-lease[=<refname>](this is what we are doing when we do--force-with-lease) (i.e., without saying what exact commit the ref on the remote side must be pointing at, or which refs on the remote side are being protected) at the time of "push" will verify if updates from the remote-tracking refs that may have been implicitly updated in the background are integrated locally before allowing a forced update.
What that means is if you're force (with lease) pushing your blah branch to origin and your origin/blah branch (the remote tracking branch) is different than the server's blah branch it stops you. This implies someone made a change you didn't know about.
There are better ways to use --force-with-lease but let's be honest, we're just looking for something quick and safe. If you want to learn about them go check out the docs. Using --force-if-includes checks your reflog in addition to the remote tracking branch to make sure there's no changes you missed.