Let's put your concerns on github on pause for a moment. I think you need to take a larger step back and look at your security risks and disaster recovery plan. You are worried that a virus could wipe out your data on your computer and you suspect that it's possible to get a virus from github. The bigger problem is that github is not going to be the sole vector for viruses and malware. Your computer could have an unpatched zero-day exploit which lets someone execute remote instructions and load in root kits or other malware. This is always a possibility for any device connected to the internet, regardless of operating system or device type. You can take all of the reasonable precautions in the world, like patching periodically, not running untrusted executables, watching your logs, consistently using AV, etc etc. But there is no such thing as perfect security.
Let's assume your computer *does* get compromised and you experience data loss and can't recover data. The less important question is how you prevent that, and the more important question is how you recover from that disaster. On a more holistic scale, viruses are only one disaster in the set of all disasters which cause data loss. Your building could catch on fire. Someone could burglarize your building and steal your computer. Your hard drive could fail. Your motherboard could fail. You could spill hot coffee all over your computer. A loose heatsink could cause your CPU to melt. You could accidentally delete your project.
The solution to all of this is backups. Back up any data you want to keep! If its important, you should have multiple copies of it and you should anticipate multiple disasters and have contingency plans in place to mitigate their effects. Source control is not a backup. Imagine you spent 50 hours writing a 60 page word document and the whole time, you *never* clicked the save button. There is no autosave. How safe is that word document? Not safe at all! Much like unsaved word documents, running without backups is very risky! My own mantra/policy is, You are only as recent as your last backup.
How often should you backup your data? Assuming the worst case scenario, the real question is "How much data can you afford to lose?". This varies by person and organization. Can you afford to lose a minutes worth of work? an hours worth of work? A days worth of work? A week? A months worth of work? A years worth of work? When you start incrementally looking at the increasing costs of unrecoverable data loss, you get a pretty good idea on what your backup schedule should look like and what the backup process should be. Usually, the less data loss you can afford, the more expensive your disaster recovery solution is going to get.
Usually for indie and small teams, you want to ideally be doing daily backups and at a minimum weekly backups. Just buy a 2-4 Tb hard drive -- they're relatively cheap compared to the cost of data loss. Backup your data, then *disconnect* the hard drive. If you can, get two hard drives and put monthly backups on the second hard drive and keep it off site somewhere (or use a cloud service provider). Periodically, you will want to verify the integrity of your backups -- I've read disaster stories where a large company had an automated backup process in place where data was backed up to tape drives and the printer would print out a report page afterwards. This automated backup process happened for years. Nobody bothered to check the backups. Then a few years later, disaster strikes! Everything is gone. Fortunately, they had been doing backups, right? Well, no. The automated backup system had been printing out a page every single day which said that the backup had failed, and since nobody had bothered to check, there was no backup to restore. The company couldn't recover and they went out of business.
Check.
your.
backups.
If anyone else is reading this, now would be a good time to pause and review your backup policy and disaster mitigation processes. It just takes a few minutes. A handful of game companies have gone under because of no backups. Don't let it be you too!
