Git: How to ignore fast forward and revert origin [branch] to earlier commit?

Question

I used

git reset --hard dc082bc... 

to revert to the branch back to a required previous state, due to some bad commits. This has rewound my local branch fine. However, I want to rewind the branch on 'origin' to the same commit so that I can start again. Could anyone tell me how to revert the origin branch (not master) to this commit?

I've tried git push origin master, but it gives the following error

 ! [rejected]        branch -> branch (non-fast-forward)
error: failed to push some refs to '[email protected]:xxx/xxx.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

Answer 1

You can try git push --force to force the push.

--force

Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check.
This can cause the remote repository to lose commits; use it with care.

So if lots of people have already pulled the same branch from origin, that can cause some rebase issue on their side.
That operation can be blocked at the server side, like ebneter points out (in the comments):

Depending on how the remote is configured, though, this may not work
-- all of my central repos are configured with receive.denyNonFastForwards = true and receive.denyDeletes = true, in which case any such surgery has to be done on the remote server.

However, in the case of GitHub, such settings are not readily available for the user managing its GitHub repo.
So if you git push --force by mistake, all you are left is opening a case to the GitHub support, for them to check their local (i.e. "GitHub") reflogs and see if they can restore old commits.
(Since reflogs are local, like I have been remembered recently. So commits which are replaced by new ones during a push --force are only still visible, if no 'git gc' or 'git prune' already took place, at the GitHub server side)

So Marco Ceppi insists (in the comments):

this could really mess up other contributors local repos if you force pushes - though are times that it is just a necessary evil (I've maybe had to do this two times in my lifespan of using Git)