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:
- Managing the naming conventions automatically
- Identifying changes between files (if they’re in a suitable format, see below)
- Merging input from different team members
- Managing different development “branches”
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 your files are in a plain text format, like HTML, CSS &Javascript, then Git can show you, very easily, the changes that have occurred between two versions.
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.
But, for best results with Git (and any version control system), I would recommend working as much as possible with plain text files eg. Markdown (for text), HTML, CSS &Javascript. How you do that, whilst still creating quality materials at speed is a topic for another post!
Resources
Graphical interfaces for Git (I prefer SourceTree from Atlassian)
Git tutorials:
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.
- Getting started – Git basics – a great introduction from the people behind Git
- The Git Parable – an easy to digest description of how Git works
- 15 minutes to learn Git
- Learn version control with Git – a good introduction, and then some focussing on the command line
- Git – the simple guide – focusses on the command line from the outset
Inspired by: 6 Myths Preventing Developers from Using Git
Posted: 25 July 2014
Tags: Content management