Version control
Git / repository / source control / repo
Version control is the permanent record of software as it changes. Microsoft describes it as taking a snapshot of the files and saving it so it can be recalled later. For a business paying for the work, it is where the asset lives, and access to it is a separate question from owning it.
The mechanism is simple and worth picturing. As a developer edits code, the version control system takes a snapshot of the files, then saves that snapshot permanently so it can be recalled later if needed. Every snapshot carries a description of what changed and why. The result is not a backup, it is a continuous record.
What that record supports is the part a buyer should care about. Team members can review history to find out who, why, and when changes were made. History gives teams the confidence to experiment since it is easy to roll back to a previous good version at any time. The alternative is the situation Microsoft names directly: without version control, developers are tempted to keep multiple copies of code on their computer, which is exactly as fragile as it sounds.
Two other things live in the same place, and both matter commercially. Version control systems provide process enforcement and permissions, so the record also decides who may change what. And it is the hook everything automated hangs from: testing, code analysis and deployment can all run when new versions are saved. The Agile Alliance puts it as an enabler of a number of Agile practices, such as continuous integration.
Which is why this belongs in a conversation about money rather than tooling. The software you commissioned lives in a repository somewhere. Owning the copyright and being able to reach the repository are different things, and the second one is what determines whether you can hand the work to somebody else on a Monday morning.
In practice
Ask where it is hosted and whose account holds it, early, while everybody is still friendly. A repository in a supplier's personal account is the ordinary case rather than the sinister one, and it becomes a problem only at the moment nobody is planning for. Moving it later is routine when relations are good and can be impossible when they are not.
Not the same as
- A backup
- A backup answers what the files looked like at one moment. Version control answers who changed what, when, and why, which is the question you have when something broke last Tuesday.
- Owning the work
- Rights come from the agreement. Access comes from an account somebody administers. A business can hold every right and still be locked out.
Why it matters to you
This is the single cheapest piece of diligence on a software project and it is almost never asked about. It takes one question at the start and it decides whether the thing you paid for is portable. It also gives you a way to see what has actually been done, in a form nobody has to write a report about.
What to ask or check
- 01Where is the repository hosted, and whose account owns it?
- 02Do we have an administrator on that account, not just a seat?
- 03If we brought in another supplier tomorrow, what would they need and who would grant it?
What people get wrong
That it is a developer convenience. It holds the permissions, the history of who changed what and why, and the trigger for automated testing and deployment, which makes it the place the work actually lives.
Red flags
- Nobody on your side able to name where the code is hosted.
- A repository owned by an individual rather than by the business.
- Code delivered as a zip file with no history attached.
Who owns it
Whoever administers the hosting account, which is a different person from whoever holds the rights. Both answers should be yours.
Where you will see it
Nowhere, until the day you need to move suppliers or find out when something changed.