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)