Why you should be using a source control system

It is 2020 and nobody should be developing software without the support of a source control system. As we will see, these kinds of tools offer great benefits with very few, if any, drawbacks.

In this article we will explain what a source control system is, and why it is so beneficial to use one if you are thinking about building a new app. Whether you are on your own or part of a larger team.

Get a free, one-day audit of your application now

What is Source Control?

A source control system, also known as a version control system, tracks the changes made by the development team to the code base of a project. It also allows them to collaborate on projects and helps maintain a secure central repository of code that can be easily managed and backed up.

Bell Labs developed first version control system in 1972. And since then these systems have been a central part of any serious software development project.

How do you use Source Control?

Work collaboratively by using separate branches

Source control systems allow users to collaborate when working on a project. For example, developers can work together on separate features by using branches. Picture a branch as a copy of the code that can evolve differently from the original (the original copy is also a branch).

Most of the time, when a piece of work has been completed, the branch is merged back to the original branch. On rare occasions branches are not merged, for example, if the feature was abandoned or the priorities of the project changed. There is no need to remove the branch, as that code may still be relevant in the future.

Choose the branching structure that works best for you

There are many ways to define the branching workflow. It is up to the team (including product owners and stakeholders) to decide what branch structure to use. Source control systems rarely impose a particular workflow but there are a few well-known strategies, like feature branching.

When using a feature branching workflow, the developers create a new branch of code for each new feature. Isolating it temporarily from the rest of the changes. With this strategy, developers and product owners are able to work in parallel on different features. Without risking code updates from one feature affecting others.

This segregation gives the product owner freedom when deciding which features to integrate with the main branch, tested and released to production. Teams can create extra branches for changes and hot-fixes again, isolating them from the ongoing development of new features.

Why should I use Source Control?

It enables automation

With application release cycles becoming shorter and shorter, it is key to automate releases to reduce the risk of human error. Modern tools like Gitlab, Azure Devops and many more, are able to detect when new code has been added to a particular branch and automatically build the application (this is known as Continuous Integration or CI).

They can even deploy it to either a test or production environment, also known as Continuous Delivery or CD. For a CI/CD pipeline to be robust, it is imperative that any code added to a branch that will automatically be released to a production system, is stable and has been tested. The use of feature branches is necessary to achieve this level of automation.

It retains a history of code changes

We mentioned earlier that a source control system tracks the changes made to the code during development, effectively keeping a copy of all the versions of every file in the project. This history of changes can be extremely useful in situations where you need to understand what parts of the code have changed from one release to the next.

For instance, you may notice that the new version of the application is not behaving as expected, even though it used to work correctly. In such cases, it is usually easier to find the issue by comparing the current version of the code with the previous one. Instead of trying to understand the problem in isolation.

Alongside each version of a file there is additional information stored that may help identify the issue. These are details like who was the author, when did the changes occur and usually a comment provided by the person modifying the file.

OK, I’m convinced, what next?

Should you find yourself in a situation where you already have a code base but it is not hosted in a version control system, don’t panic. Adding your source code to a version control repository can be straightforward.

1. Choose a source control system and decide if you want to host it or use a fully managed system in the cloud

Cloud based systems are a lot easier to work with as you won’t need to manage any of the infrastructure. Nowadays git is the most popular source control system and most online services will support it.

Check out these links to find out more about git and some of the other providers:

https://guides.github.com/

https://docs.gitlab.com/ee/gitlab-basics/

https://git-scm.com/

2. Create your account and set up your access keys

Whichever provider you choose will supply detailed instructions on how to do this for their platform.

3. Upload your code to the system and start using it

From now on your source control system will start to track the history of changes!

Summary

As we have seen, there are many advantages to using a version control system; from reliability, security and auditability, to flexibility in deciding what features can be released next. In addition, it provides the development team with an excellent way to collaborate and merge their work together.

If you are a key stakeholder for a software development project, you should ensure the code is managed in a source control system. In this day and age, there is no valid reason not to use a version control system.

If you’re not sure where to start, our free, one-day audit of your application includes a source code review by one of our Solution Architects, so get in touch now if you’d like more information.

Luis Soler

View posts by Luis Soler
As Head of Technology, Luis provides leadership and guidance to the rest of the Scrum team on how to design, and implement each project we work on. He is involved in every stage of the project lifecycle and development process, from design to development, support and infrastructure.