Download Squad

You'll notice that I left out media content such as digital photos or music files. Most version control systems are designed for software development and mainly deal with plain text files. Though binary files can be stored in the repository, being binary means difference comparison between versions aren't possible. If you have a large quantity of digital media content to manage, it is generally better to use specialized management tools than version control systems.

The When
So how often should you commit your changes to the repository? The answer is kind of straightforward for software developers because their stopping points tend to be either a) the application compiles successfully, b) the tests run with no failure, or c) the new feature works/bug is fixed.

For non-developers, it is less clear cut. My rule of thumb is that if you start tinkering with whatever you are doing instead of 'working', it is an indication that you have reached a plateau and it's time to commit your changes.

For example, let's say you have been modifying a bunch of files for a new blog template. At some point the blog will look half decent and your mind may begin to wander to the 'next big thing'. That's the point you want to commit all your changes to the version control system. This way, if your 'next big thing' turns out to be the next big dud, you can easily revert back to the moment where you took a wrong turn. Depending on how you work, this can mean committing changes every 15 minutes to an hour. The thing to remember is 'commit often'.

Summary
I hope I've given enough information to encourage wider adoption of version control. It might feel a bit disruptive to your day to day work in the beginning but very soon committing files will become second nature -- just like saving files is now -- More importantly, the benefits a version control system bring to any one with content to manage outweigh the slight learning curve; You trade just a little pain in the short term for big gain in the long run.