I am 100% sure that's what I want to keep!

That's very rarely true, especially for newbies.

And your caps problem is likely due to using Windows or Mac OS X, which default to case-insensitive filesystems.

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.

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.