If the situation is an urgent one, and you just want to do what the questioner asked in a quick and dirty way, assuming your project is under a directory called, for example, "my project":
QUICK AND DIRTY: depending on the circumstances, quick and dirty may in fact be very GOOD. What my solution here does is NOT replace irreversibly the files you have in your working directory with files hauled up/extracted from the depths of the git repository lurking beneath your .git/ directory using fiendishly clever and diabolically powerful git commands, of which there are many. YOU DO NOT HAVE TO DO SUCH DEEP-SEA DIVING TO RECOVER what may appear to be a disastrous situation, and attempting to do so without sufficient expertise may prove fatal.
Copy the whole directory and call it something else, like "my project - copy". Assuming your git repository ("repo") files are under the "my project" directory (the default place for them, under a directory called ".git"), you will now have copied both your work files and your repo files.
Do this in the directory "my project":
.../my project $ git reset --hard [first-4-letters&numbers-of-commit's-SHA]
This will return the state of the repo under "my project" to what it was when you made that commit (a "commit" means a snapshot of your working files). All commits since the "reset
ted" commit will be lost forever under "my project", BUT... they will still be present in the repo under "my project - copy" since you copied all those files - including the ones in the repo, under .../.git/.
You then have two versions on your system... you can examine or copy or modify files of interest, or whatever, from the previous commit. You can completely discard the files under "my project - copy", if you have decided the new work since the restored commit was going nowhere...
The obvious thing if you want to carry on with the state of the project without actually discarding the work since this retrieved commit is to rename your directory again: Delete the project containing the retrieved commit (or give it a temporary name) and rename your "my project - copy" directory back to "my project". Then maybe try to understand some of the other answers here, and probably do another commit fairly soon.
Git is a brilliant creation but absolutely no-one is able to just "pick it up on the fly": also people who try to explain it far too often assume prior knowledge of other VCS [Version Control Systems] and delve far too deep far too soon, and commit other terrible crimes, like using interchangeable terms for "checking out" - in ways which sometimes appear almost calculated to confuse a beginner.
To save yourself much stress, learn from my scars. You have to pretty much have to read a book on Git - I'd recommend reading THE BOOK, Pro Git 2nd edition: available for free download etc. from git central. Published 2014 but, as at early 2022, still the best. Do it sooner rather than later: Git is destined to be part of your life from now on. If you do, bear in mind that much of the complexity of Git comes from branching and then remerging: the Pro Git book actually introduces this central aspect very gently, but you can skip those parts in any book on your first read. From your question there's no reason why people should be blinding you with science.
Especially if, for example, this is a desperate situation and you're a newbie with Git!
PS: (slight caution) One other thought: It is (now) actually quite simple to keep the Git repo in a directory other than the one with the working files. This would mean you would not copy the entire Git repository using the above quick & dirty solution. See the answer by Fryer using --separate-git-dir
here. Bearing that in mind, be warned: If you have a "separate-directory" repository which you don't copy, and you do a hard reset, all versions subsequent to the reset commit really will be lost forever forever, unless you have, as you absolutely should, regularly backed up your repository, preferably to the Cloud (e.g. Google Drive) among other places.
On this subject of "backing up to the Cloud", the next step is to open an account (free of course) with GitHub or (better in my view) GitLab. You can then regularly do a git push
command to make your Cloud repo up-to-date "properly". But again, talking about this may be too much too soon: git push
has to be configured, can fail to work for a totally baffling technical reason, involves learning about remote repos ("origin", etc). So a quick-and-dirty Cloud-based backup approach may be preferable until you become knowledgeable. Again, the Pro Git book introduces how remote repositories work, and relate to your local repo, very gently and rationally.