The same way you write a book, a website is also 'written'. Somewhere, code is written on a blank sheet of paper. A feature is created, things are adjusted and pieces of code are sometimes rewritten. So a lot is changing in the 'codebase' of your digital channel. And there are often multiple developers working on the same website. Sometimes they all work on their own feature, but sometimes they all work on the same one. They may even have to work in the same file.

This creates different versions of the same website that are on the computers or servers of multiple developers. This becomes very confusing and there is a high chance that mistakes will be made or bugs will arise in the code. You can prevent this by making good use of version management.

Git as a version control tool

With version control you ensure that everyone working on your project stores their work in one central point (the repo or repository), that changes to files are tracked and that all code comes together in one version. You need certain tools for version control. The most important tool is the one for version management itself. Git is often used in the development world for version control.

Git works with so-called 'branches', or branches. These branches contain certain versions of the codebase or certain features that are being worked on but are not yet ready. The names of branches are free, but many repositories have branches that contain the live version of the website (the master branch), a version that runs on development or staging (the development branch) and there are branches that only contain the code of a certain feature or template state. Uniform naming and consistent use of branches is very important within a development team. This creates clarity and reduces the chances of errors.

Code changes: commits

A developer works for a number of days on a certain feature or on certain templates. The work is often divided into pieces. First the header is created, then the body, then the footer, then the contact form, etc. All these additions and adjustments cause changes in the code. You want to keep track of those changes. This way you can see exactly what you have created and you can also look back at how certain things were developed at an earlier point in time.

The changes to the code are tracked in 'commits'. It's good practice to commit, or save, every step you've taken in developing a feature to the Git repository. Each commit also contains a 'commit message'. That is a brief description of the work that has been carried out. This way you keep a nice overview of the progress and fellow developers can clearly see which code is used for what.

Bringing different sectors together

By working in branches, different developers can more easily work on different features of the website simultaneously, without overwriting each other's code. But, at a certain point a feature is ready or the template is finished and then of course all the code has to come together. That is the moment when you bring different branches together to create a new version of the codebase. Bringing branches together is called 'merging'.

For example, you first merge different feature branches into the development branch. You deploy the development branch to a development environment so that everything can be properly tested as a coherent whole. Once you have tested all the new features and everything works properly, you can deploy to the staging environment. If everything works well there, then everything can be transferred to the live environment. Only the master branch runs on the live environment. So if everything works well on staging, merge the development branch into the master branch and deploy the master branch to the live environment.

In the unlikely event that something goes wrong live, you can easily go back to a version with Git and deploy it. See the power of good version management here.

Below in the image you see a visual representation of a repository containing branches that come together again (the colored lines), commits and commit messages. You can also see in a commit which code has been added (the green shaded area with plus signs in front).

source tree example
A screenshot of Sourcetree, a GUI for working with Git. Source: https://blog.sourcetreeapp.com/2017/01/27/sourcetree-for-windows-2-0-is-now-in-beta/

Why is working with version control and Git so important?

You now have a general idea of ​​how version control works. So you no longer have to be surprised when your agency talks about branches, Git and commits because now you know exactly what they mean by it. Most agencies and professional web agencies all use Git or some form of version control. Below is a brief explanation of why it is so important to use version control:

  • Version control makes it easier for multiple developers to work on different or the same features, files and codebase without getting in each other's way. With Git they have a powerful tool with which they can properly bring together all the code they create. They can easily view and track changes in the codebase.
  • There is a good overview of the codebase and the changes to it. For example, you can better detect bugs or determine which piece of code is not yet working properly.
  • Working with Git and version management is completely in line with SCRUM and Agile working. You write user stories and use cases out, you create tickets in the backlog and link those tickets to branches in Git. This way you keep a good overview of which code and commits belong to which tickets.
  • It gives a lot of meaning to the codebase. Developers can clearly see what has been done per change / commit and with the correct commit message it also becomes clear why and for what purpose.
  • You always have a backup of your codebase, including past code. With a Git repository you never have to worry about whether your codebase is still backed up. Everything is in the repository, including the version of your site from a year ago.