You need to make sure that no other users of this repository are fetching the incorrect changes or trying to build on top of the commits that you want removed because you are about to rewind history.

Then you need to 'force' push the old reference.

git push -f origin last_known_good_commit:branch_name

or in your case

git push -f origin cc4b63bebb6:alpha-0.3.0

You may have receive.denyNonFastForwards set on the remote repository. If this is the case, then you will get an error which includes the phrase [remote rejected].

In this scenario, you will have to delete and recreate the branch.

git push origin :alpha-0.3.0
git push origin cc4b63bebb6:refs/heads/alpha-0.3.0

If this doesn't work - perhaps because you have receive.denyDeletes set, then you have to have direct access to the repository. In the remote repository, you then have to do something like the following plumbing command.

git update-ref refs/heads/alpha-0.3.0 cc4b63bebb6 83c9191dea8

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.