There are a handful of developer technologies that can revolutionise the way that you work. Version control is one of them and an absolute must if you’re working in a team. In this article we’ll be looking at what version control is, how it can help you, and where to start.
Version control is essentially used to manage the changes to your project files with each change referred to as a ‘revision’. You can store a complete copy of your project as well as concurrent different versions (known as branches) and a full history of how the project has progressed. Revisions can be compared, restored and merged, which is particularly useful when working in a team.
While version control has many benefits, its greatest strength is to facilitate teamwork. If you’re working by yourself you’ll likely have one copy of a project and no one interfering with your code, but what happens when more than one developer is working on the same project? Tracking the changes you’ve made would be a nightmare and the potential for conflicts would be high! Types of version control vary (we’ll get to that), but essentially each developer will have their own working copy of the code, potentially with a ‘master copy’ that will be centrally stored on a version control server. Developers can ‘branch’ the code to develop or trial new features and when they’re finished version control will take care of merging the code and assist in resolving any conflicts. Best of all – if anything goes wrong there’s a complete backup of all the changes!
So to summarise a few key benefits:
- Facilitates multiple developers working on the same project
- Automatic backups – complete history of what you’ve worked on
- Ability to trial different features and easily roll back
To get started with version control you’ll need to decide where and how you want to store your files. There are two main choices you’ll need to make:
- Which ‘type’ of version control are you going to use? The most common are SVN and GIT. There is wide debate over which is better - I think the short answer is it depends on what you need it for, ultimately they both achieve the same result. The key difference is that SVN is considered a ‘centralised system’ whereby there is one main version of the code stored on a server, whereas GIT is a ‘distributed system’ where you ‘clone’ the repository for the site along with all the history. In my opinion SVN is a simpler concept when you’re getting started, though GIT offers superior features for speed and backups as it is distributed. Being the simpler of the two, we’ll look at setting up SVN in the next section as a lead up to the next article on deployment strategies. There is a wealth of articles on the GIT vs SVN debate if you want to learn more however.
- The second question is which hosting service you wish to use (some are free, some are not). The most popular GIT services are GitHub and BitBucket, both of which offer free accounts with limitations. One of my SVN favourites is SpringLoops - as they offer a free account for one repository I’ll recommend using this service today. As a side note, I should point out you can also set up your own SVN or GIT server, though this obviously involves a bit more work and management.
The below outlines some of the key concepts you’ll need to know:
The trunk is a full version of the code considered to be the ‘base’ of the project. One thing you’ll come to learn with version control is that many of its features can be used differently. While it’s entirely possible to work solely on the trunk, it’s arguably better to create new features on a ‘branch’ (coming up) to ensure that the trunk is a stable version of the project. The trunk is essentially an unnamed branch...
Branches are used to develop new features without affecting the working version of the project. Once the new feature is complete and tested the branched code can be merged back into the trunk.
Tags allow you to mark a version of the code at a specific point in time. This is useful as a restore point or to compare against a future version of the project. A tag can be considered a snapshot of the code. Not wishing to confuse matters, but there isn’t technically any difference between tags and branches as they are both just copies of the code.
Checking out code involves getting a copy from the repository, you can check out everything in the repository or more commonly a section such as the trunk.
Once you’ve checked out a copy of the code and have finished working on the trunk or a branch, you would then commit your code which would send it back to the SVN server. For another developer to then receive these changes they would update their code. The one area where the terminology is a bit more straight forward!
So, you’re up to speed on the key concepts and you’ve made up your mind on how and where you want to store your files; now you can go ahead and create an account with your preferred service and create an empty repository for your project. In Springloops this is simply a case of creating a new project (allow it to create the default folders for branches and tags), you’ll then be able to view the ‘Source access details’ which will provide you with a repository URL that looks something like this: https://yourproject.slsapp.com/source/yourproject
The next thing we need to do is get access to this repository on your local machine. To do this we need a handy piece of software called TortoiseSVN (note TortoiseGIT is also available). Download and install the software with the default settings. Once completed, create an empty folder where you want to store your project (note, if you have existing files you can copy these into the repository later). With the new software you’ll now see that if you right click the folder there is an option to do an ‘SVN Checkout’:
Click this option and copy in the repository URL that you obtained from Springloops, and then append ‘/trunk’ so that you don’t check out all the branches of the code. Clicking ‘OK’ will then ‘check out’ the code from the trunk of the repository, which at this point will be empty. Once this is complete you can now copy in your project files into the folder if you have an existing application, or if it’s a new project you can start creating your folders and files. In the interest of this tutorial, we’ll create a folder titled ‘public’ and inside this folder we’ll create an index.html containing some ‘Hello World!’ text. Now that your project is set up with the repository, if you right click the same folder you’ll notice you can now ‘commit’ the code, which will push it back up to the hosting service.
Take a sigh of relief – you don’t have to worry about backups anymore!
In the next tutorial I’ll be looking at how we can harness some of the benefits of version control to integrate it with a deployment strategy. Stay tuned.