Git version control
Every line of your software, who changed it and why — and the reason you can undo a bad Tuesday.
Version control
Chosen per project
Maintainable handover
Version control is the least negotiable thing on this list. Without it there is no reliable way to know what is running in production, no way to undo a change safely, and no way for two people to work on the same system without overwriting each other.
We still meet businesses whose software exists as a folder on a developer’s laptop, with the previous version in a zip file. Putting that into Git — and making sure the client owns the repository — is usually the first thing worth doing.
What we build with Git
Any software project with more than one contributor or more than one version
Bringing an undocumented, unversioned codebase under control
Establishing what is actually deployed to production
Handing over a project with its full history intact
Where it fits — and where it does not
Good fit when
All software work, without exception
Configuration and infrastructure definitions as well as application code
Documentation that must stay in step with the code
Consider something else when
Large binary assets, which need Git LFS or separate storage
Secrets and credentials, which belong in a secret store, never in a repository
How a change reaches production
Four gates. Skipping any of them is how untraceable code ends up live.
Branch
Work isolated from what is currently released.
Review
A second pair of eyes before merge.
Automated checks
Tests and linting must pass to merge.
Tagged release
What is deployed is identifiable and revertible.
How we work with Git
A branching model that fits
Short-lived feature branches and a protected main branch — not a model copied from a company with fifty engineers.
Reviewed merges
Changes reach main through a pull request, so at least two people have seen anything that reaches production.
Meaningful history
Commits that explain why, not just what, because in two years the history is the only documentation left.
Client ownership
The repository sits in the client’s organisation from day one, with our access removable at any time.
Our typical Git setup
| Concern | What we use |
|---|---|
| Hosting | GitHub, GitLab, Bitbucket or Azure Repos — your choice, your account |
| Branching | Protected main with short-lived feature branches |
| Review | Pull requests with required approval and passing checks |
| Secrets | Kept out of the repository; scanning enabled to catch mistakes |
| Large files | Git LFS or object storage rather than committed binaries |
Frequently asked questions
You do. It is created in your organisation account, and our access can be removed the day an engagement ends without anything being handed over manually.
Yes. The existing versions can be imported as a starting history, and everything from that point is properly tracked. It is a short piece of work with a disproportionate benefit.
Almost certainly not. For most teams a protected main branch with short-lived feature branches is enough, and the elaborate models cost more than they return.
Topics people search for
Services built with Git
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Software Maintenance
Keeping working systems working — including ones built by somebody else.
Digital Transformation
Moving a business off paper and spreadsheets without stopping the business to do it.
Enterprise Software Development
Systems for organisations where several departments, sites and approval chains all have to work from the same data.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.