9

Friendly Reminder: Git is not a fucking backup solution. It's a VCS. They are not the same.

You CAN and SHOULD use rsync or what-ever-backup-you-fancy alongside it, lest you get owned by hardware failure, git repo corruption (yes that shit DOES exist), rm -rf stupidity or any other manner of annoying tech bullshit.

If you make a push for every little change. Stop. If you rely on Git to "save" your repo in the cloud. Stop. If you think your machine doesn't have a chance of just *eating shit* one day. Stop.

Worried about spies? Then you have "gocryptfs" or "cppcryptfs" et cetera for encrypting your local repo. No excuses.

Comments
  • 5
    Or.. shit happens and instead of just throwing around "backups save lives" we just hand off info that may work to restore the repo to its older state, to late now to restore from a non existent backup.

    Granted, backups should exist, I can't remember the last time I ever backed up my own hdd, that's not to say servers are backup-less though.
  • 1
    You should push regularly anyway so your coworkers can continue work on the feature if you don't come to work tomorrow.

    There's just an added benefit that you never lose enough work that it would be worth it to restore a backup.
  • 2
    Pushing for every small changes and rebase -i / amend FTW
    Why use a separate backup solution when we have a very good tool that does a great job at it ?
  • 2
    @MagicSowap Oh God please don't amend a commit that's already been pushed...
  • 4
    @EmberQuill as long as it's on your own branch it's ok
    And rewriting history can be very useful to make it more clear, separate the concerns, etc

    You all sound like you push directly to origin master lol
  • 0
    @MagicSowap true. It was more of a gut reaction because I've dealt with some badly-managed projects where a rebase or amend from a coworker can ruin your whole day.
Add Comment