01What it is
Version control is a record of every change ever made to an application's code. For each change it stores what changed, who changed it, when, and a short note on why. Any earlier state of the code can be brought back at any time.
Compare it with a shared document where people save copies called final, final_v2 and final_really. Version control replaces that with one history in which every step has a name, an author and a date, and in which two people can work on the same files without overwriting each other.
The standard tool is Git. Linus Torvalds wrote it in 2005 to manage the code of the Linux operating system, and today almost every software project uses it. The code itself is usually kept on a hosting platform such as GitHub, GitLab or Bitbucket, where the team can see the history, discuss changes and control who has access.
02How it works
The whole code of an application, together with its history, lives in a repository. Every developer works on a copy of it, and the copy on the hosting platform is the one everyone agrees on.
Four terms cover most of what happens day to day:
- Commit: a saved step. It bundles a set of changes to one or more files with a message such as "Show the due date on invoices". Commits are numbered with a unique code and can be looked at, compared or undone one by one.
- Branch: a separate line of work. A developer starts a branch for one task, makes commits on it and leaves the main line untouched until the task is finished.
- Pull request: a proposal to take the work from a branch into the main line. It shows every changed line, red for removed and green for added, together with a description of what the change does and why.
- Merge: accepting the pull request. The commits from the branch become part of the main line, and the history records who approved them.
03Review before merge
The pull request is where quality is checked. Someone other than the author reads the change, asks questions, requests corrections and finally approves it. On most platforms the main line can be protected, so that nothing reaches it without an approval and without the automatic tests passing.
This step is also where a business owner can follow the work without reading code. Each pull request has a title and a description in plain language, a link to the task it belongs to and the result of the tests. A list of merged pull requests is a list of everything that changed in the application, in order.
04An example from a business application
Suppose a company uses a web application for its invoices, and the accountant reports that credit notes show the wrong VAT rate since last Tuesday.
With version control, the developer looks at the history of the file that calculates VAT and sees that a pull request merged last Monday changed it. The description says the change added a new discount type. The developer reads the lines it touched, finds the mistake, writes a fix on a new branch and opens a pull request that refers to the one that caused the problem. A colleague reviews it, the tests run, and the fix is merged the same day.
If the fix had needed more time, the developer could have reverted the faulty change on its own. Git creates a new commit that undoes exactly those lines, and every other change made since then stays in place.
05Alternatives
Before Git, centralised systems such as Subversion (SVN) were common. They keep the history on one server, and developers have to be connected to it for most operations. Some older companies still use them. Git keeps the full history on every copy, which makes it faster and lets people work offline.
Among hosting platforms, GitHub is the largest. GitLab offers similar features and can also be run on a company's own servers. Bitbucket belongs to Atlassian and is often chosen by teams that already use Jira. All three use Git, so a repository can be moved from one to another with its full history.
Working without version control, with code in folders, on a single developer's laptop or sent around as zip files, still happens in small projects. It means there is no reliable record of what changed and no clean way back when something breaks.
06What to check when you buy software
If someone builds software for you, the repository is the most valuable thing they hand over. These questions are worth asking before a project starts:
- Whose account is the repository in? Ideally it sits in an organisation on GitHub or GitLab that belongs to your company, with the developers invited as members.
- Will you receive the complete code, including scripts and configuration, and the documentation needed to run it?
- Does every change go through a pull request with a review, or do developers write straight to the main line?
- Are the automatic tests connected to the pull requests, so that a change with failing tests cannot be merged?
- Are passwords and access keys kept out of the repository? They belong in the hosting provider's settings.
07How we use it
All our code lives on GitHub. Every change, whether one of us or one of our AI agents wrote it, goes through a pull request. The agent that writes a change never approves it: other agents review it for mistakes, for data quality and for security, the automatic tests run, and one of us two signs off before it is merged.
Changes to sign-in, permissions or passwords get a separate security review on top. Each pull request describes in plain language what it does, so the history doubles as a log of every decision.
At handover the client receives the code in their own GitHub account and can continue with us, with another team or on their own.
Frequently asked questions
Do I need a GitHub account?
Only if you want to own the repository yourself, which we recommend. A free GitHub organisation for your company is enough. We invite ourselves as members and you can remove us at any time.
Can I see what changed in my application?
Yes. The list of merged pull requests shows every change with a title, a description and a date. Reading the descriptions requires no programming knowledge.
What happens if a change breaks something?
The change is found in the history and either fixed or reverted. Reverting creates a new commit that undoes exactly that change, and all other work stays in place.
Is my code public on GitHub?
No. Repositories can be private, and ours are. Only the people invited to the repository can see the code.
Can another developer continue the work later?
Yes. Git and GitHub are the industry standard, so any developer can take over the repository with its full history and see why each part was built the way it was.