Commit Often, Perfect Later, Publish Once: Git Best Practices

sethrobertson.github.io

117 points·dhotson··4 comments

"This is because essentially every clone is a backup."

Tags are essentially backups, too. If you tag a commit, you can always get back to it, or repoint a new branch at it. And you'll preserve all history leading up to that point.

They don't back up your whole git repository exactly as it was, of course.

Would you say that SHAs are essentially backups too?

Author means backup as in, something to use for disaster-recovery, not a mistaken 'git reset --hard HEAD~100 && git push -f'.

If you hold a commit ref but it becomes unreachable (ie. it isn't tagged, a branch tip, or an ancestor of something that is a tag or a branch tip), then it'll expire eventually and be removed. So no, keeping a record of that ref doesn't necessarily protect you. Using a tag additionally ensures that the ref remains reachable, and then git won't garbage collect it.

> Author means backup as in, something to use for disaster-recovery

Looking back at the article, I don't think it's really clear what he means. For disaster recovery, you should be backing up at the filesystem level (and he does say this). For accidents in the use of git, then tagging will hold a commit and all its ancestors, which is normally what you want. For more major accidents (maybe filter-branch, or rm -Rf .git), I rely on my regular system backups, but you might just keep a copy of the entire working tree, including the .git directory.

It's clear that for backup the author means, backup for disaster-recovery purposes. There is no other reason to backup a git repository, and the previous "Don't Panic" section covers recovering from git fumbles. The mailing list thread he links to in the Backup section details a traditional off-site rsync backup.

Reply on news.ycombinator.com