What is version control?

Version control is one of the most fundamental things in modern software development, but also one of the things rarely explained to the buyer. It’s worth understanding, because it directly ties into one of the most important questions of all: do you actually own your code? Here’s what it means.

The definition

Version control is the system that records every change to a project’s code, along with information about who made it, when, and why. Instead of the code just existing in a single, constantly changing state, a complete history is built up, where every step is preserved and can be returned to.

It solves two problems at once. First, you can always roll back to an earlier state if something goes wrong – an infinitely more powerful undo function. Second, many developers can work in the same codebase in parallel without overwriting each other’s work, since the system keeps track of and merges the changes.

Git is the standard

In practice, version control today almost always means Git. It’s the tool that handles the history itself, and it has become so dominant that it’s the obvious standard in nearly every professional development team.

On top of Git sit services like GitHub and GitLab. They store the code centrally in a secure place and add everything that makes teamwork smooth: code review, access control, issue tracking, and automated tests. Git is the engine under the hood; GitHub and GitLab are the platforms where the team gathers around the code. The difference is worth knowing, because it’s on the platform that your access as a buyer lives.

Two terms: commit and branch

Two words come up constantly, and they’re simpler than they sound.

A commit is a saved change. Every time a developer finishes a piece of work, the result is saved as a commit – a named point in the history with a short description of what was done. It’s like placing a bookmark after every completed step, so you can always find your way back.

A branch is a parallel working copy of the code. There, a developer can build something new or try an idea without touching the working code already in production. Once the work is finished and tested, the branch is merged back into the main line. Branches are what let several people build different things at the same time without getting in each other’s way.

The buyer’s angle: require access to the repo

Here’s where it becomes business-critical. All code in a project should sit in a version-controlled repository – a repo – and what matters is who has access to it.

If the code sits in a repo that you as the buyer own and have full access to, you’re in control. You can review what’s been built at any time, bring in another vendor to continue where the last one left off, and be confident the entire history remains. If the code instead only sits with the vendor, you’re stuck: you’re dependent on their goodwill to reach your own system, and ending the relationship can become very expensive.

The requirement is simple to state and should be stated early: all code should sit in a version-controlled repo that your organization owns or has administrator access to. It’s one of the cheapest insurance policies against vendor lock-in there is. At Weapp, we see it as a given that the buyer owns their code – after all, you’re the one who paid for it.

How to use this

You don’t need to know Git to ask the right questions. Ask where the code is stored, whether it’s version-controlled, and make sure you’re listed as owner or administrator on the platform, not just as an invited guest. Then you have both the history and control of your system, no matter how the collaboration develops. Want help sorting out how your code is managed today? Get in touch.