This is why I keep my working copies in Dropbox

second that... my working folders are dropbox... and commit to cloud git repository as needed.

Same here. I had some sort of electrical problem with my last computer and lost my hard drive due to it. Unfortunately, my back-up drive was also plugged in at the time and it got fried, as well (really bad luck/timing there).

One of the first thing I did when I got the new computer was to put a symlink to my projects directory in my Dropbox folder, so that all of my projects now get backed up to Dropbox automatically.

We keep our main repository in under dev/$PROJECT and backup repositories under user/$USERNAME/$PROJECT. Then we set a post-commit hook to push to the backup server on commit. Setting up the backup and creating the hook is done by a shell script you run after cloning.

Raid and rsync are your friends. Use them.

I'm always doing

  git push origin develop

for this reason, but some environments probably don't allow you to do this easily? I work alone. (EDIT: be nice to people)

We typically work in personal feature branches before merging into develop; if you use a similar workflow there shouldn't be much issue at all from pushing constantly.

Can you protect from other folks pulling it? Sometimes people just don't want to reveal their code while is ugly...

Gitolite[1] will let you mark branches as private on the remote either by specific branch name or a regex (ex: any branch that starts with "swah-" is private to you) if you want privacy before revealing your code.

[1] http://sitaramc.github.com/gitolite/

Dropbox fixes this.

You could buy a second hard drive and put it behind your other drive and occasionally copy important files from your front drive up to your back drive.

Works great until your computer/home/office catches fire.

Personally I have a mirrored drive set that I use as my primary storage, and a third disk that I rsync to nightly and use for backups of other stuff, because I don't trust that I won't have filesystem errors or controller problems that might render both disks in the mirror unusable. Then on top of that I use Crashplan to ensure I have an offsite copy.

For most of my code I also push to github or private external repositories regularly and/or pull to my laptop.

Maybe a bit paranoid, but I've had to recover from enough scary hardware and software failures over the years to not want to take risks.

Or use TimeMachine if you are on a Mac.

No, if TimeMachine screws up a file it stays screwed up for ever after every backup, there's no integrity checking. It also completly barfs on large files that change little by little. The best example of that is the entourage mail store, but any single file db will do. I've seen clients bit bad by these problems. Don't get me started on the time capsule...

Option-click on the Time Machine menu to verify backups. Sleep well.

What should we use instead?

Linus's solution is to write software that people run and use daily.

Point your Time Machine backups at a NAS that's using ZFS with block-level deduplication.

What's wrong with a remote branch you push to and then merge back into master afterwards?

Was my second sentence really that incomprehensible?