Our advice is to not directly back up software development files, or development environments such as Git or Eclipse. Instead, have a script periodically create an archive of the development files in a location that SpiderOak One or Groups is monitoring. There are several benefits of this. First, what the backup application has to watch is a single file that is updated infrequently rather than thousands of files and subdirectories, so system load is kept to a minimum. Second, what gets backed up is data at rest, so the possibility of file corruption and difficulties during recovery are minimized.
Apropos the second point, you should schedule the script to run during times that the files will not be in the middle of active change. You will also want the archive to be no larger than 1 GB or so. SpiderOak can handle larger files than that, but for performance reasons, the smaller the better. Compressing the archive before SpiderOak backs it up is a good idea. In particular, gzip with the --rsyncable option is a good choice to not lose the advantage of SpiderOak's deduplication.
Software development files, and development environments, can be reliably backed up if done as described above. They should not however be synced. There are ways to synchronize development files (e.g.
git pull) and we are not trying to duplicate such tools.
For more information on what to back up, see What Data to Select for Backup.