As you point out git will happily trash your universe if you ask it to, and it makes it so easy to ask it to.
If I was the boss of git I would remove all --force options. Sadly I'm not, but I can and do strongly recommend that you don't *use* them -- and certainly not on a repo that other people have access to.
The very fact that you have to use a series of hard to remember commands and options to accomplish what ought to be smooth and simple is what damns git
My point, which I stand by, is that a series of easy to remember and understand commands is sufficient.
e.g.You realise that what you have just committed and pushed needs one little change that you forgot, or you realise that there's a typo in the commit message for something you've just committed and pushed, and in either case you want to fix the problem quickly before some poor sod pulls what you've just screwed up.
Stop right there.
You're right. You've screwed up. Git is designed to be (and is) a faithful and non-forgeable record of the history of a project, mistakes and bugs and all.
Pushing a spur of the moment change to the master branch of a public repo without reflection, testing, and preferably review is more than somewhat unprofessional.
Force pushing a fix to pretend it never happened is simply terrorism.
Even if it is only 30 seconds, on a busy project someone else may already have pulled, and then your force-push screws them *totally*. Just don't do it. Own your screw up and push the fix on top of it.
Blaming the situation on git is like mashing the accelerator of your Camry all the way to the floor and leaving it there and then blaming Toyota for the ensuing crash.
There is logically no smooth and simple and invisible recovery from this situation in a public repo. Other revision control systems such as svn don't let you even pretend there is. As I said, git should arguably not have the force option available on commands, and certainly not on push. We can't change that now, but we *can* tell people DON'T USE IT.
If you don't want to have careless screw-ups and subsequent fixes in the public permanent record then don't put them there. Git has plenty of mechanisms to help you avoid them, such as local and public feature branches and reordering and combining commits as you copy them from one branch to another, and then finally merging tested a reviewed changes to master.
This is something that git supports a thousand times better than svn or cvs or others.