
Commit Often, Perfect Later, Publish Once: Git Best Practices - dhotson
http://sethrobertson.github.io/GitBestPractices/
======
rlpb
"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.

~~~
falsedan
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'.

~~~
rlpb
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.

~~~
falsedan
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.

