Most of us start out creating documents and other materials without any system of version control in place.
But, very soon, we realise that we need to keep regular backups (usually just after something has gone horribly wrong). So we start saving things with filenames like xyzclient-elearning\2014-7-10\v13.docx. Being human though, we tend to forget things like the precise format to use, or whether we have overwritten a particular file with the current version. It can get very messy very quickly.
Things become even more complicated when we’re working with a team, or trying out new ideas whilst still maintaining the main set of materials. It’s so easy to make mistakes and end up publishing the wrong version to the client.
This is where a version control system, like Git™ can help, by:
I prefer Git to other systems (such as SVN), mainly because of its speed, the fact that I can work locally, but also with a team, and because managing changes in different development branches is very easy.
Git works by taking a snapshot of all your files in a project every time you tell Git to do so. It stores a copy of any file that has changed, and a reference to the previous identical file for files that haven’t changed.
If you’re working with documents in proprietary formats (as used by most of the Rapid Elearning tools), then Git just treats them as “blobs”, and saves a new copy of the whole file each time. This might be exactly what you want, as you don’t need to worry about fancy naming conventions.
In fact, I use Git quite often just to support version control of Word documents and project plans.
It’s a good idea to understand the concepts behind Git, and a smattering of commands before using one of the graphical interfaces, otherwise you’ll get lost quite quickly.
Inspired by: 6 Myths Preventing Developers from Using Git
Posted: 25 July 2014