Comment by andybak
4 years ago
A lot of people seem to regard version control as an adequate substitute for an automated offsite backup. This strikes me as a dangerous habit. There are too many gaps between "what I want to commit to a repo" and "what I would hate to lose in the event of a total system failure".
It's better to keep the two things separate. I'm happy with Backblaze on all my machines - although they have a disturbing habit of making unannouced changes to their default exclude filter which tripped me up (no VM images I knew about. But adding .git directories nearly lost me data). You can override these filters but they really shouldn't be changing them without clear warning.
> There are too many gaps between "what I want to commit to a repo" and "what I would hate to lose in the event of a total system failure".
You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally, and push branches to a remote for backup. Then, you should form your “permanent” commits from that work. The thing is, you have to get comfortable with git. For example, one common move is:
1. Commit everything 2. Make a temp branch (remember that “branches” are just labels for a commit; they cost nothing) 3. Switch back to the first branch 4. Use git reset to uncommit the last few commits 5. Clean up the code and commit it properly, with a good commit message 6. Run tests and check the diff from your temp branch to check you didn’t make a mistake when cleaning up
This tool Dura is totally unnecessary for people who are comfortable with git.
> You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally,
I agree - but that doesn't invalidate my original statement. I think you might have misunderstood my point. See my other reply above.
Yes, I think I stick to my ground. I'll address your points below. There are two camps here:
1. A large number, possibly a majority, of people who aren't yet familiar enough with git. Those people think of commits as being final: a commit is what you will push to the remote, your colleagues will see, and gets stored in public git history forever. They haven't yet learned that branches cost nothing, how to work with temporary branches, and how to create a new series of commits from already-committed work.
2. People who know git well and are the complement of the above set in all ways.
I'm sure you're right that backup systems have their place, but your comments here about how git shouldn't be used for backups are aligning with the camp (1) folks and making it harder for them to see that git can be used to save their work frequently, once they learn git better. Ultimately, positions like the one you're taking contribute to people developing misconceived tools such as TFA.
> 1. everything else on your system (potentially - a lot of stuff depending on your workflow
Sure -- backing up random files is good. I use google drive for that personally.
> 2. everything you've .gitignored (you 100% sure that's all ok?)
Yes, I don't worry about this. .gitignore is itself under git's control, so whatever's gitignored for me, is gitignored for my colleagues, therefore the project works without standardized content in those file paths.
> 3. changes not yet pushed
What reason is there ever to not push a branch that contains work you wouldn't want to lose? Planes and other no-network situations is one: I just push as soon as I'm on network. I never leave valuable work unpushed if I have a network connection.
> 4. branches that don't exist on remote
Why haven't you pushed them?
> 5. git stuff that's invaluable for disaster recovery
Not sure what you mean here
> 6. git stashes
Yes, good point to raise. Store work you're not prepared to lose in branches, and push them. You can stash it as well if that's convenient.
You probably know this, but the biggest hurdle newcomers to git face is they don't understand that branches are cheap, and they don't understand how easy it is to undo changes by using temp branches with `git reset --hard` and `git checkout`. Rather than telling them to supplement git with a backup system, it would be better to teach them to get comfortable using git. TFA is an extreme example, talking as if ctrl-z undo is an inevitable workflow for a git user when, in fact, it's only something that beginners do for more than trivial undo operations.
5 replies →
Why shouldn't the repo be treated as a backup, if it is set up to be backed up? And who doesn't back up their work repos?
It is a backup but it's a partial backup that excludes:
1. everything else on your system (potentially - a lot of stuff depending on your workflow
2. everything you've .gitignored (you 100% sure that's all ok?)
3. changes not yet pushed
4. branches that don't exist on remote
5. git stuff that's invaluable for disaster recovery
6. git stashes
and probably other things i haven't thought of.
Backups should be:
1. Offsite
2. Automated
3. Recent and up to date
4. Comprehensive
Git workflows usually only handle point 1