Now bear with us if you think, based on that title, that this post isn’t for you or you’ll get lost in the technical jargon. We have found that across our whole team, learning about version control is a great way to understand how the sausage (AKA – a website) gets made by development teams.

There are many great benefits of version control. It improves visibility and accelerates the development process, helps teams collaborate and tracks all changes made and by whom. At IGNITE, we use GitHub and Bitbucket to facilitate version control. 

What is version control?

In its most basic sense, version control keeps the repository of code (i.e the website) untouched while the devs can work on it in pieces and make changes (i.e. on a branch). It maintains a record of who’s done what so developers can collaborate on changes and, in the worst-case scenario, roll back any change that breaks the code to the previously working version. 

We find analogies work well here, so think of it like a book. 

The repository is the whole book sitting on the shelf ready to be read. With version control, instead of taking the whole book off the shelf and writing new text on the page (we’ll explain why that’s a BAD idea later), we instead take a copy of the page we want to work on (a branch) and work on it separately while the book stays on the shelf ready to be read. When the work is complete on our pages we submit a pull request and put the updated pages back in the book.

TIPS FOR GOOD VERSION CONTROL

A GOOD NAMING STRATEGY

A good general rule is to use naming conventions to distinguish what type of work is being done on the branch. This will make it easier for other devs to work out what’s being worked on and by who.

We do this by breaking down the branch being worked on into three categories. Feature, Bugfix or Hotfix.

A feature is exactly that, a feature is created in the code, a Bugfix is a small bug that needs to be fixed but not too urgently, and a Hotfix is a “Damn the site’s breaking. Fix it!” type of update that needs to happen ASAP.

We then add a descriptive outline after the category, for example, bugfix/fix-homepage-button-colour. This ensures that if someone on the team needs to look for a branch they are easy to find. 

Make sure you name the branches after what changes are actually happening. In some cases, we’ve seen branches are named after the developer, which makes it really hard for other devs to review separate changes.

AUTOMATED TESTING & DEPLOYMENT

Automation is an incredibly important part of version control. You can automate testing to take place when you write new code, so if there is an issue, testing ensures that you do not push bad code that will break other functionality in the repository.

Automated deployments build up all the code changes and deploys them to the server without the devs having to do this manually. This doesn’t sound like a lot but if your devs upload five changes a day to 10 different repositories, it definitely adds up!

CODE REVIEW

Two heads are better than one, especially when it comes to essential work like coding. We’ve found that the best practice is to have two developers check the code before merging it into the production/live branch. Not only is it helpful to review code, but it also presents an excellent opportunity for developers to learn from each other. For example, Junior devs can learn from Senior devs’ code changes and their approach to implementing particular changes.

WHY USE VERSION CONTROL

As we mentioned before, not everyone uses version control when making changes to their code. The main benefit of version control is that it avoids the messy process of making changes to the production version of code. This also provides a platform for developers to avoid overriding errors that have already been resolved or other outdated versions that may have existed in the past. 

We hope we didn’t lose you in the fray and you learnt something. If you’re interested in working with us, you can check out our recent projects or reach out to us.