But then those commits are still in the wrong branch. If I accidentally commit something to master instead of a development branch, I can't deploy master until my development branch is merged in, as the one commit isn't ready for live.
If you haven't pushed, it's as easy as resetting the branch to the last good commit. If you have pushed, well, it's the same, then push -f, and then making sure that all your teammates pull the fixed branch. If that's a situation you regularly find yourself in, protecting master from direct pushes and only doing PRs is a good solution (GitHub, BitBucket and GitLab all have tooling for this).
Maybe it's just me but I feel like if you work with multiple developers you should never, ever force push master. I'm wary of force pushing branches in general, unless that's a branch that only I work on.
It's not ideal, at all -- and if someone else has pushed in the meantime, they risk losing the commit. But if you're in a situation where doing this would be a significant problem, you should probably not be pushing directly to master in the first place, instead relying on a PR workflow.
Because that will pollute the history and diminish its value as a record of what happened in the code base. For instance, blame will no longer tell you when a line was changed, but rather point to the revert commit. Bisect breaks if it divides through the reverted commits.
Of course, rewriting history is only feasible immediately after the mistaken commits, before anyone builds on top of them. If they've lingered, reverting is the right way.
And again, if this is a repeating problem, fix it upstream (no pushing to master, only PRs).
That's where tools like github and gitlab come in (or a pre-receive hook on the server), which can deny all commits to master. If that's something you want to prevent of course - and tbf, as soon as there's more than one or two people working on a project, I'd lock master down.
