Just do:

git push origin <your_branch_name> --force

or if you have a specific repo:

git push https://git.... --force

This will delete your previous commit(s) and push your current one.

It may not be proper, but if anyone stumbles upon this page, thought they might want a simple solution...

Short flag

Also note that -f is short for --force, so

git push origin <your_branch_name> -f

will also work.

You should be able to force your local revision to the remote repo by using

git push -f <remote> <branch>

(e.g. git push -f origin master). Leaving off <remote> and <branch> will force push all local branches that have set --set-upstream.

Just be warned, if other people are sharing this repository their revision history will conflict with the new one. And if they have any local commits after the point of change they will become invalid.

Update: Thought I would add a side-note. If you are creating changes that others will review, then it's not uncommon to create a branch with those changes and rebase periodically to keep them up-to-date with the main development branch. Just let other developers know this will happen periodically so they'll know what to expect.

Update 2: Because of the increasing number of viewers I'd like to add some additional information on what to do when your upstream does experience a force push.

Say I've cloned your repo and have added a few commits like so:

            D----E  topic
           /
A----B----C         development

But later the development branch is hit with a rebase, which will cause me to receive an error like so when I run git pull:

Unpacking objects: 100% (3/3), done.
From <repo-location>
 * branch            development     -> FETCH_HEAD
Auto-merging <files>
CONFLICT (content): Merge conflict in <locations>
Automatic merge failed; fix conflicts and then commit the result.

Here I could fix the conflicts and commit, but that would leave me with a really ugly commit history:

       C----D----E----F    topic
      /              /
A----B--------------C'  development

It might look enticing to use git pull --force but be careful because that'll leave you with stranded commits:

            D----E   topic

A----B----C'         development

So probably the best option is to do a git pull --rebase. This will require me to resolve any conflicts like before, but for each step instead of committing I'll use git rebase --continue. In the end the commit history will look much better:

            D'---E'  topic
           /
A----B----C'         development

Update 3: You can also use the --force-with-lease option as a "safer" force push, as mentioned by Cupcake in his answer:

Force pushing with a "lease" allows the force push to fail if there are new commits on the remote that you didn't expect (technically, if you haven't fetched them into your remote-tracking branch yet), which is useful if you don't want to accidentally overwrite someone else's commits that you didn't even know about yet, and you just want to overwrite your own:

git push <remote> <branch> --force-with-lease

You can learn more details about how to use --force-with-lease by reading any of the following:

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

If I’m understanding correctly, you’re talking about a scenario like the following:

1. You have a repo named ben3eee/some-repo
2. You create a few commits on branch some-branch
3. You push some-branch to ben3eee/some-repo on GitHub using git push
4. You squash the commits into one using git rebase -i
5. You  force push some-branch to ben3eee/some-repo on GitHub using git push -f
6. You now want to restore some-branch to the way it was before step #4

The great thing about Git though is that it does it’s very best to never lose data, so the version of the repository before step #4 is still available as long as too much time hasn’t passed. The exact definition of “too much time” is kind of fuzzy and depends on how many other changes you’ve made between step #4 and step #6. For this example, I’m going to assume that you realize your mistake right away and no other actions were taken other than the ones in the list above.

The command that can help is called git reflog. You can enter git reflog and see all of the actions that have changed your local repository, including switching branches and rebases, going back quite a ways. I’ve created a simple reflog that shows the scenario I described above:

b46bfc65e (HEAD -> test-branch) HEAD@{0}: rebase -i (finish): returning to refs/heads/test-branch
b46bfc65e (HEAD -> test-branch) HEAD@{1}: rebase -i (squash): a
dd7906a87 HEAD@{2}: rebase -i (squash): # This is a combination of 2 commits.
a3030290a HEAD@{3}: rebase -i (start): checkout refs/heads/master
0c2d866ab HEAD@{4}: commit: c
6cab968c7 HEAD@{5}: commit: b
a3030290a HEAD@{6}: commit: a
c9c495792 (origin/master, origin/HEAD, master) HEAD@{7}: checkout: moving from master to test-branch
c9c495792 (origin/master, origin/HEAD, master) HEAD@{8}: pull: Fast-forward

You can see at HEAD@{7} I performed a checkout moving from master to test-branch. I then created three commits, “a”, “b” and “c”. Then I rebased them, arriving at HEAD@{0}. The notation HEAD@{number} is the position of HEAD at “number” changes ago. So HEAD@{0} is HEAD where HEAD is now and HEAD@{4} is HEAD four steps ago. We can see from the reflog above that HEAD@{4} is where we need to go in order to restore the branch to where it was before the rebase and 0c2d866ab is the commit ID (also sometimes called “SHA”) for that commit.  So in order to restore test-branch to the state we want, we can issue the command:

git reset --hard HEAD@{4}

Then we can force push again to restore the repository on GitHub to where it was before.