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 iOS bug report: strange backstack behavior when navigating to a file #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.