My naive approach would be to start a new Git environment, push the whole project into the master branch and then continue to develop the project using Git as if it had been there all along.

That seems like a perfectly good approach. If you don’t have the history of what you’ve done so far in any convenient form then you can’t get that history into Git. If you have some old versions, but not tracked as any systematic series of versions, then it’s unlikely to be worthwhile converting that series of ad-hoc versions into a Git history.

So probably the best thing is to just add all files that make up the current version of the project (excluding anything that needs to be kept secret) to a Git repository and then use Git to track changes from now on.

I’ve done this a couple times. What I usually do (if using Github) is create a new empty repo on Github, clone it locally, copy my code into it, and push it all up.

If u were doing any sort of release-management, eg a zip file, any time u made changes, u could incramentally put the contents of each into git, starting with the oldest, or if u had a regular backup of the code being made, u could restore a backup for each days work and put the contents of each into git, starting with the oldest.