In summary, use cherry-pick to apply specific commit diff's (by hash) to a new branch. Makes perfect sense. I also use this technique all the time with github projects where I just want a bug fix or two from someone else's fork.
You don't even have to cherry-pick. Use git reflog to find the topmost correct sha1 (or in the example, right after the rebase, HEAD@{4}), and then do
git checkout -b revovery
git reset --hard HEAD@{5} #(the checkout made HEAD change, hence +1)
or even faster:
git branch recovery -f HEAD@{4}
The key here is to understand that git commit objects include a reference to their parents, and that git merely constructs a branch's history by evaluating the ref to a sha1 and walking over objects recursively. So to recover we merely make something point at the topmost sha1.
Then, in the case of additional commits that came after the squash, you use git rebase --onto to replay the commits that came after the squash on top of the unsquashed commits, which would give us:
git checkout -b recovery
git rebase --onto last_sha1_before_squash squashed_commit_sha1 recovery
The checkout -b is just so that rebase will handily move that pointer for us (see man git-rebase)
while rebase will replay commits from squashed_commit_sha1's child up to the commit currently pointed at by recovery, over last_sha1_before_squash (again, see man page)
Recovering seemingly lost commits is really important skill to have when working with git. However, it is infinitely easier with the git reflog command.
