--force-with-lease

Rewriting a pushed commit makes your branch diverge from its remote copy, and the remote refuses a push that is not a fast-forward. --force overrides that blindly, deleting whatever else arrived; --force-with-lease does so only if the remote branch is still where your remote-tracking branch says it is:

# Edit README.md: reword the Development section
git commit -qa --amend --no-edit
git push
git push --force-with-lease

To ../server/booknest.git
 ! [rejected]        dev-docs -> dev-docs (non-fast-forward)
...
To ../server/booknest.git
 + 4307965...031219b dev-docs -> dev-docs (forced update)

Now the laptop pushes a commit to dev-docs while booknest, unaware, amends again and force-pushes:

cd ../laptop
git fetch -q && git switch -q dev-docs
# Edit README.md: list npm run dev in the Run it block
git commit -qam "List npm run dev under Run it"
git push -q
cd ../booknest
# Edit README.md: reword the Development section again
git commit -qa --amend --no-edit
git push --force-with-lease
git fetch -q
git push --force-with-lease --force-if-includes

To ../server/booknest.git
 ! [rejected]        dev-docs -> dev-docs (stale info)
error: failed to push some refs to '../server/booknest.git'
To ../server/booknest.git
 ! [rejected]        dev-docs -> dev-docs (remote ref updated since checkout)
...

The server's dev-docs no longer matched origin/dev-docs, so the lease failed ("stale info") and the laptop's commit survived. But any fetch, even an editor's background one, updates origin/dev-docs and lets the next lease through. --force-if-includes (Git 2.30 1,932 ) closes that hole by also requiring the remote tip to be in your branch's reflog, that is, integrated. Make that pair your only force-push. A server repository can refuse rewrites outright with receive.denyNonFastForwards true.