I don't think you're going to get your changes back if they were never staged or committed. Accepting incoming changes applies those changes to your working copy, which is the most volatile place and means unless your operating system has some form of restore functionality or you made a copy of the entire repo and working copy before you started, you're out of luck, sorry.
To avoid this happening again, I recommend getting to grips with git reset
, as you rightly suggested it would be the answer if you hadn't already lost your working copy changes (also you could have committed to a branch first before pulling in the remote changes):
git reset --soft [ref]
will change the branch that HEAD is pointing to, to whatever [ref]
is. [ref]
could be HEAD~1
, which would mean "the revision before HEAD". Note this changes the branch, not just the HEAD pointer. So if HEAD is pointing to MAIN, then it's MAIN that'll move and you'll have dangling commits (you can find them again using git reflog
as long as you don't make too many changes or wait too long before looking for them).
git reset --mixed [ref]
will do the same as git reset --soft
, but will also update the index to match (i.e. will leave your working copy with your changes alone).
git reset --hard [ref]
will so the same as git reset --mixed
, but will also update the working copy to match the index. This is the dangerous one as you could lose your unstaged, uncommitted changes.
See https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified for more details. Sorry for your loss.