If you push a commit to the server, and then rewrite that commit locally (with git reset, git rebase, git filter-branch, or any other history manipulation), and then pushed that rewritten commit back up to the server, you will screw up anyone else who had pulled. Here’s an example; say you have committed A, and pushed it to the server.
-*-*-A <-- master -*-*-A <-- origin/master
Now you decide to rewrite A, in the way you mentioned, resetting and re-committing. Note that this leaves a dangling commit, A, which will eventually be garbage collected as it is not reachable.
-*-*-A
\
A' <-- master
-*-*-A <-- origin/master
If someone else, let’s say Fred, pulls down master from the server while you’re doing this, they will have a reference to A, which they might start working from:
-*-*-A' <-- master -*-*-A <-- origin/master -*-*-A-B <-- fred/master
Now if you were able to push your A’ to origin/master, which would create a non-fast-forward, it wouldn’t have A in its history. So if Fred tried to pull again, he’d suddenly have to merge, and would re-introduce the A commit:
-*-*-A' <-- master
-*-*-A <-- origin/master
-*-*-A-B-\
\ * <-- fred/master
A'--/
If Fred happens to notice this, then he could do a rebase, which would prevent commit A from reappearing again. But he’d have to notice this, and remember to do this; and if you have more than one person who pulled A down, they would all have to rebase in order to avoid getting the extra A commit in the tree.
So, it’s generally not a good idea to change history on a repo that other people pull from. If, however, you happen to know that no one else is pulling from that repo (for instance, it’s your own private repo, or you only have one other developer working on the project who you can coordinate with easily), then you can forcibly update by running:
git push -f
or
git push origin +master
These will both ignore the check for a non-fast-forward push, and update what’s on the server to your new A’ revision, abandoning the A revision so it will eventually be garbage collected.
It’s possible that force pushes are entirely disabled with the receive.denyNonFastForwards config option. This option is enabled by default on shared repositories. In that case, if you really, really want to force a push, the best option is to delete the branch and re-create it, with git push origin :master; git push origin master:master. However, the denyNonFastForwards option is enabled for a reason, which is described above; on a shared repository, it means that now everyone who uses it needs to ensure that they rebase onto the new history.
On a shared repository, it is generally better to just push new commits on top that fix whatever problem you have; you can use git revert to generate commits that will undo the changes of previous commits.