Do not directly back up software development files, development environments, or version control systems such as Git, Bazaar, 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 to this indirect approach. 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. Also for performance reasons, leave the archive uncompressed: SpiderOak will compress, deduplicate, and encrypt it in any case. If you must compress the archive before SpiderOak gets to it, gzip with the --rsyncable option is a good choice to not lose the advantage of SpiderOak's deduplication.
Software development files, development environments, and version control systems can be backed up as described above. They should not however be synced. There are ways to synchronize such things (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.