It's always an eventful start to the morning when a coworker is panicking about lost code. If you use Git, however, the resolution is fairly painless.
My coworker pulled down the develop branch from the remote and did a rebase on his branch. Panicking commenced as he discovered his most recent commit disappeared. But if you know Git, you understand there's a disconnect between doing a normal rebase and a commit vanishing. So, I got him to walk through exactly what he did. After watching the steps he took, I discovered he ran git rebase --skip after getting frustrated with conflicts during his rebasing. So, the code from develop was successfully pulled into his branch, but after running into a conflict, he skipped his most recent commit instead of resolving the conflict. Thus, his commit was not applied.
Excellent. We now know what caused the issue and why his commit disappeared, but how will we get his code back? Well, thankfully, Git doesn't just delete your code. Your commit might be orphaned, but it's not gone. So, how do we find it?
The commit is no longer in the branch he's working with, but it used to be. So, we run git reflog to see his recent history including commits. From this log, he found his commit and copied the SHA-1 hash for that item he needed to go back to. Then it was just a matter of running git reset --hard sha-hash-here. After running that, he was back where he was prior to rebasing and ––skipping. He then rebased again but avoided ––skip and instead resolved his conflict and ran git rebase --continue.
As easy as that, the commit was back and the conflicts were properly resolved. As you can see, unless you have a good reason, try to avoid using git rebase --skip.