Version control gives every software change a history, an owner and a route into production. Used properly, it makes collaboration, review, recovery and future handovers far easier.
01
Two sensible changes can still create one confusing release
Imagine an established service business relies on a customer portal. Customers upload documents, staff review cases and managers use the system to see what needs attention.
A developer is asked to change the upload rules. At the same time, somebody else needs to fix the email sent after a case is submitted. Both changes are reasonable. Both are urgent. Both touch the same part of the application.
Without a controlled change history, the work quickly becomes awkward. One person has a copy on a laptop. Another edits files on the server. A folder called “latest” appears beside one called “latest-final”. The portal stops sending emails after the release, but nobody can say which edit caused it or exactly what reached production.
The immediate problem is a broken email. The larger problem is that the business cannot answer basic questions about its own software: what changed, who changed it, why it changed, who checked it and which version is running now.
Version control exists to give those questions reliable answers. It is a technical tool, but its real value is operational control.
02
Version control records how files change over time
A version control system records changes to a file or group of files so an earlier version can be inspected or restored later. Software teams use it for source code, configuration, database migration files, tests and the documentation kept with an application.
Instead of saving another complete copy of the project every time something changes, the system keeps a structured history. A developer can compare two versions, see which lines changed, identify the recorded author and read the message explaining the change.
That history is kept in a repository, often shortened to repo. The repository contains the project files and the records used to rebuild their history.
Git is the distributed version control system used by many modern software teams. Distributed means each working copy can contain the project history, rather than every useful action depending on one central server. Git is not the only version control system, but it is the one most people will meet today.
This is already better than folders with dates in their names. The bigger improvement appears when the team agrees how changes move through that history.
03
Git and GitHub are related, but they are not the same thing
Git records the changes. GitHub is a hosted platform that stores Git repositories and adds ways for people and automated tools to work around them.
A team can use Git without GitHub. It could host repositories on GitLab, Bitbucket, Azure DevOps or its own server. The choice of platform matters for access, security, integrations and ownership, but the underlying Git history remains a separate idea.
GitHub adds useful controls such as pull requests, reviews, protected branches, issue links, automated checks and releases. These features turn a file history into a working change process.
For the customer portal, Git can show that the email code changed. A GitHub pull request can also show why it changed, the discussion around it, the test results and who approved it before it joined the main codebase.
That distinction matters during a supplier handover. “The code is on GitHub” is not enough. The business needs access to the organisation, repository, history, settings, automation, documentation and any connected deployment service needed to operate the application.
04
A commit should tell one small, useful part of the story
A commit is a recorded snapshot of a set of changes. It includes a unique identifier, author information, a message and a link to the commit that came before it.
Good commits are small enough to understand. “Prevent confirmation email when submission fails” is a useful unit of work. “Updates” attached to three weeks of mixed changes is not.
Small commits make comparison, review and investigation easier. If the portal starts sending the wrong email, a developer can inspect the relevant change rather than searching through a large bundle containing styling, dependency updates and an unrelated report.
The message should explain the purpose, not simply repeat the filename. The diff already shows that a condition changed. The message can explain that the old behaviour sent a confirmation before the case was stored successfully.
A commit is still not an approval or a release. It says that a change was recorded. The next controls decide whether that change is ready to join the main application.
05
Branches keep unfinished work away from the main application
A branch lets a developer continue from one point in the history without changing the main line of development. In Git, branches are lightweight, so teams can create them for fixes, features and experiments without copying the whole project into another folder.
The upload-rule change can live on one branch while the email fix lives on another. Each developer can make commits, run tests and adjust the work without placing unfinished code into the version intended for release.
When the change is ready, it can be merged into the main branch. Git compares the histories and combines them. If both branches changed the same lines in incompatible ways, Git reports a conflict that a person must resolve.
A merge conflict is not Git failing. It is Git refusing to guess which meaning should win. That is far safer than silently overwriting somebody else's change.
Branches should normally be short-lived and focused. A branch that remains separate for months becomes harder to review and harder to merge because the main application keeps moving without it.
06
Pull requests create a place to review the decision
A pull request proposes that the changes on one branch should be merged into another. It gives the team a place to inspect the difference, discuss the reasoning, request changes and record approval.
The most useful pull requests explain the business reason, the intended behaviour, how the change was tested and any risk or follow-up work. They connect the code to the job it is meant to do.
For the portal email fix, the reviewer should be able to see the failed scenario, the new behaviour and the test that protects it. They can notice that the change affects a background queue or ask what happens when the email provider is unavailable.
Code review is not a guarantee that a defect will be found. It gives another person a structured chance to question the change before production. It also leaves a decision record for the person investigating the application six months later.
A sole developer can still use pull requests. Self-review after a pause, automated checks and a written explanation are weaker than independent approval, but they are much better than an unexplained direct edit on the main branch.
07
Protecting the main branch turns good intentions into a control
A written process is easy to ignore when a release is urgent. Repository rules can make the important parts of the process harder to bypass.
GitHub branch protection can require a pull request, approving reviews, successful status checks and resolved conversations before work enters an important branch. It can also restrict who may push, and it blocks force pushes and deletion by default when protection is applied.
Status checks normally come from continuous integration. A service builds the application, runs automated tests, checks formatting or performs security analysis whenever a proposed change is updated. A failed check does not prove the idea is wrong, but it stops a known problem from quietly moving forward.
Choose controls that match the risk and the size of the team. A two-person application does not need the same merge queue as a platform receiving hundreds of changes each day. It may still need one approval, a passing test suite and no direct pushes to main.
The aim is not ceremony. It is a repeatable route that gives the business a reasonable answer when somebody asks how production changes are checked.
08
Tags and releases identify what the business is actually running
A clean main branch still does not tell you which point in its history reached production. The deployment process needs to record that connection.
A Git tag marks a specific commit. A release can add a readable version name, release notes and packaged files around that point. The deployment system can then record that version against the production environment.
For the portal, a release such as `2026.08.31.1` can identify the exact code deployed after the email fix. If a problem appears, the team can compare that version with the one before it and see what changed between them.
Rolling back the code may be possible, but it is not always the safe answer. A release might include a database migration, data conversion, queue change or external API update that cannot simply move backwards. Recovery planning must cover the whole application, not only the files in Git.
That is why a useful release record includes database changes, configuration needs, deployment steps and any manual action. Version control supplies the code history. Release discipline connects that history to the running service.
09
Version control is not a complete backup or recovery plan
Git can recover tracked files and history, but it does not automatically protect everything the business needs.
A repository may not contain customer uploads, the production database, secret values, cloud settings, third-party account access or the conversations stored only on the hosting platform. Some repository features and large-file content also need separate backup decisions.
Even the repository itself needs a recovery plan. GitHub documents mirror cloning as one way to back up a repository and its revision history. Depending on the features in use, metadata such as issues, pull requests, packages and large-file objects may require additional work.
Keep secrets out of the repository. Removing a password in a later commit does not make the earlier copy disappear from history. Treat an exposed credential as compromised, rotate it and then clean the history carefully when required.
| Control | What it helps answer | What it does not prove alone |
|---|---|---|
| Version control | What changed in tracked files, when and by whom | That the change was reviewed, deployed or safe to run |
| Pull request and checks | Why a change was proposed, discussed and allowed to merge | That production received the same version successfully |
| Release and deployment record | Which code version was sent to an environment | That live data, integrations and user journeys still work |
| Backup and restore test | Whether important code, data and files can be recovered | Why a change was made or whether the restored application is correct |
The right question is not whether Git or backup is better. They protect different things. Important business software normally needs version control, repository backup, database backup, tested restore steps and a record of what was deployed.
10
Repository ownership is part of application ownership
The customer portal may have a perfect Git history and still be difficult to take over if the repository belongs to a former supplier's personal account.
The business should know which organisation owns the repository, which named people have administrator access, how multi-factor authentication is enforced and what happens when a developer or supplier leaves. Access should match the job, and old access should be removed promptly.
The repository should also contain enough context for another capable developer to begin safely. That normally includes setup instructions, the required runtime and dependencies, test commands, deployment notes, database migration history and a clear explanation of where secrets are managed.
Do not put every operational detail into a public README or store passwords beside the code. Keep sensitive runbooks and credentials in suitable controlled systems. The repository should point an authorised person towards the right information without exposing it.
A good handover is not a zip file sent on the final day. It is working access, understandable history, documented controls and a tested route from a new developer's machine to a non-production environment.
11
Start by making one important change traceable
The customer portal does not need an elaborate branching philosophy on day one. It needs one repository the business controls and one agreed route for changing production.
Put the current source code under Git. Make sure the business has administrative access to the hosted repository. Protect the main branch. Ask developers to use focused branches and pull requests. Run the most valuable automated checks before merge. Tag releases and record what reached each environment.
Then test the awkward scenario. Could a new developer clone the repository, follow the instructions, run the application and explain the most recent production change? Could the business remove an old supplier without losing control? Could the team identify the code version running when a customer reports a problem?
Those answers reveal whether version control is part of a working delivery process or simply somewhere the code happens to be stored.
The real benefit is not a prettier commit graph. It is knowing that every important software change leaves a trail the next person can follow.
Useful questions
Before relying on a software repository, ask:
- Does the business control the repository organisation and administrator access?
- Is the current source code and relevant configuration under version control?
- Are changes small enough to review and explained by useful commit messages?
- Do developers use focused branches instead of editing the main branch directly?
- Do pull requests explain the reason, testing and risk behind each change?
- Are reviews and important automated checks required before merge?
- Can the team identify which tag or commit is running in production?
- Are database changes, secrets and deployment requirements handled separately and safely?
- Is the repository and its important metadata included in a tested backup plan?
- Could another capable developer set up and understand the application from the available documentation?
