On the Indie Game Developers Facebook page, everyone seems to recommend using "Git" to manage different versions of a game. As a solo developer, I don't really see this as necessary, but I am open to other opinions and reasons why I should consider it.

Is anyone using git or some other similar type of repository? Are these things compatible with 3DGS projects?

at it's base, git is just something that keeps track of your project's files and remembers all changes / versions you uploaded. there is more complex functionality (branch and merge, etc.) but as it's mostly working with the files themselves I don't see why it should be incompatible with anything.

IMO, Git or some other VCS is pretty much necessary for anything more complex than a fast weekend prototype. Also it's a must if you have more than 1 person touching the code.

I do not know how it would fare for binary files (Models,levels,textures etc) but for source code and other text git is the king. It does not matter which language/engine you use. For git a text file is a text file.

You can create free private repos on bitbucket.org and free open-source(public) git repos on github.com

For a single developer i'd suggest a simple branch/tag system, like one master, one development and an occasional snapshot of the master as a version.

Like, do all your development work on development branch, as you complete features merge them to master and from time to time take snapshots of master and version them like v1, v1.1 v1.2 and so on.

This means, at any given moment, master is working / compiles correctly, and nothing is half finished or under development there. You work on dev branch, and once something is done/complete merge it to master.

Also read-up a little on git. Some people do single commit everyday after they are done for the day, this could work as simple code backup system but not what git is actually for. Commit every change related to a single feature as it's own commit (so the work you done on every feature is a separate commit) and push them to development branch every evening instead. This way you can roll-back/shelf a single feature 3 days later and do not have to roll everything you did in that past 3 days back. Once your features are done and you deem current development branch is fit to be merged to master merge it. For a larger team i would merge each feature separately to master, but for a single developer that's too much branches and starts getting too time-consuming and micro-managey so i think it's ok for a single dev to occasionally merge latest dev state to master.

Also do not try to do what i explained with 10 lines of code or try to set up this stuff before you actually start working. Work on your project first, when you reach a point you think you need to back it up, open a repo on bitbucket, push everything to master, keep working and pushing everything to master until you think your project is grown enough to utilize the branching system i explained, check everything is ok with your project and start a development branch and go from there as i explained above.

ALSO half of what i said is bullshit depending on who you ask. So, as i said, read up on it.