FWIW, multiple backups and hardlinks are the basic foundation of git. Running 'git commit -a' a few times a day to check in all the changes isn't a big timesink; commit messages can take time or not depending on how detailed you care to be.
I've has some personal projects that were 'moving too fast' for version control, or that I was just playing around with. In every case I ended up losing code because I couldn't remember how I'd done something I'd later removed. And I've never had a project with more than one copy of the codebase -- whether that's a local dev and a production deployment, or two devs -- that didn't end up overwriting code or config at some point.
It's not surprising that version control, largely useful for history, does not appear to be immediately useful for a young project. But young projects become old projects with the same habits and practices. Start with good ones.
Comments
FWIW, multiple backups and hardlinks are the basic foundation of git. Running 'git commit -a' a few times a day to check in all the changes isn't a big timesink; commit messages can take time or not depending on how detailed you care to be.
I've has some personal projects that were 'moving too fast' for version control, or that I was just playing around with. In every case I ended up losing code because I couldn't remember how I'd done something I'd later removed. And I've never had a project with more than one copy of the codebase -- whether that's a local dev and a production deployment, or two devs -- that didn't end up overwriting code or config at some point.
It's not surprising that version control, largely useful for history, does not appear to be immediately useful for a young project. But young projects become old projects with the same habits and practices. Start with good ones.