Why Version Control Isn’t Just For Rude Emails

Have you ever drafted a tricky email so many times that you lost track of which one would be the best to send? Usually your first draft is the least polite, so it can be pretty important to get things right!

As a coder you might expect me to say this, but making sure that the strings of characters which make up a piece of software are taken from the right draft is probably even more important.

Like any other language, the code in which we write apps and all other digital gadgets and widgets is sensitive: get something in the wrong place or wrong format, and it won’t make sense. That’s why one of the most important parts of any kind of software development is version control.

Like that tricky email, we tinker with code over time to make sure it says – and therefore does – exactly what we want it to. Having a place where all of the code for all of our projects lives, and where we can see the code changes/history of any given project, is therefore absolutely crucial – if something breaks, we can see why by making comparisons with previous versions. If something works better, we’ll also know why. (To be fair, I also enjoy finding out who’s to blame for breaking stuff!)

Developers who control their versions protect your code – and therefore your investment. At Image+, when we start a new project, we create what is called a repository that will hold all of the code for that project. As development progresses, we commit our changes to the repository along with a message that describes those changes. This produces a log of all the changes to the code throughout the history of the project and allows us to keep track of what’s going on. When we need to get the latest changes, we pull them from the repository.

There are a number of version control packages which do this, but we use the sector-leading, and unfortunately monikered, Git. One of the major advantages of using Git – and it needs plenty to make up for that name – is its ability to handle merging.

That is, when two of us are working on the same project and one commits a change, Git will automatically find the differences and merge them together when we “do a pull” onto our local development environment. This means that more than one developer can work efficiently on your project at any one time without … well, accidents happening.

Another big advantage is the use of branches. For example, we might set up multiple branches of a project’s code, to maintain our code across the multiple life-stages of a project, from initial work to testing to final production. All this enables us to manage those projects which we host for clients more effectively and seamlessly – and, therefore, cost-effectively.

That’s why we recommend that we host your project. Self-hosting can feel like storing your own code in your own space, but allowing your developer to host your project so that they can use version control (amongst other things) is a great way of making your project smarter, quicker and more efficient – rather than painstaking and frustrating. (In an earlier draft of this blog, ‘painstaking’ and ‘frustrating’ were ruder words. And so version control proves itself again.)