Reflog is your friend - See:
https://github.community/t/i-accidentally-force-pushed-to-my-repo/277
If I’m understanding correctly, you’re talking about a scenario like the following:
You have a repo named ben3eee/some-repo
You create a few commits on branch some-branch
You push some-branch to ben3eee/some-repo on GitHub using git push
You squash the commits 59 into one using git rebase -i
You force push some-branch to ben3eee/some-repo on GitHub using git push -f
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.