git reset --hard origin/master
is the culprit here. Read that command as "reset the index, discard all modified files, check out all the files at origin/master, and move the current branch head to the commit at origin/master." It sounds like you had a merge conflict and you handled it with a knife that is a little too sharp.
Good news is that as long as you've got the original repo you did it in, you can at least get back any files you previously committed. Use git reflog
to find the previous version of your commit and use git reset --hard <commit hash>
. This will get your current branch back to the state it was in before you started.
No you'll need to integrate the changes on the remote into your current changes (what you did was replace your local changes with the ones on the remote. You have two options for this, git merge
and git rebase
:
Fetch first to get everything on the remote and update your remote references. (git pull
is essentially git fetch
and git merge
rolled into one command, thought it can be configured to rebase instead). The fetch is non-destructive and allows you to decide exactly how you want to deal with the issue.
If you don't mind a merge commit and a slightly messier history, you can now run git merge origin/master
and deal with any conflicts that arise. Then you can push and you'll be up to date.
If you would prefer a straight line of history, you can run git rebase origin/master
which will replay your divergent commits on top of the master head. Conflicts may occur at more than one commit on reply, resolve each, stage and run git rebase --continue
to resume.
Excellent documentation is available on dealing with conflicts in both situations, so I won't go into detail here.