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: