Rebasing is complicated, and was probably a bad idea in this situation. Let's adopt your topology:
o---o---o---o---C1---o---o---o---o friend
\ \
o---o---o---o---M---o---o---o me
To pick up your friend's changes, the right and simplest thing to do was (on me):
git merge friend
That would give this:
o---o---o---o---C1---o---o---o---o friend
\ \ \
o---o---o---o---M---o---o---o---M2 me
You cannot coherently rebase at this point, despite what your friend said, because me already includes a merge commit (M) from friend. Rebasing can't easily cope with that; it will ignore the merge commit, and thus the effect of the merge will be undone in your branch. There are ways around this, but it's not worth going into them here.
The key question now, however, is how to get out of the mess you've gotten yourself into with a bad rebase followed by a bad merge. The answer is to use the reflog, which makes much of what you do in Git undoable. When you say git reflog you will be shown a list of all previous states of your HEAD. One of these will be the state just before you started the rebase. You want to go back to that by saying git reset --hard <SHA> (as I explain here). Now do the merge that you should have done, and move on.