Nobody would accept a set of accounts with no dated entries, no way of telling who changed what and when. Yet a great many professional websites live exactly like that: edited straight on the live server, with no trace, no author and no way back. This article explains what a code repository brings, without asking anyone to learn to program, and it raises the question that too rarely gets asked: who actually owns the code of your site.
The problem version control solves
Four situations come up again and again, and a repository makes them disappear.
- Nobody knows what changed. The site worked on Friday and not on Monday. Without a history, the investigation starts from nothing. With one, it starts from a dated list.
- Two people overwrite each other. One developer fixes a page template while another edits it through the online editor. Whoever saves last wins, and the other loses their work without ever knowing it.
- A change breaks the site and nobody knows how to go back. So a full backup is restored, which wipes out the orders and articles published since.
- The provider leaves, and the knowledge of the site leaves with them. This is the most expensive case, and the most common.
Version control is not a developer’s luxury: it is insurance on the continuity of the tool your business runs on.
Git, GitHub, repository: the vocabulary in five minutes
The repository
The binder that holds the site’s code and the whole of its history. It can be duplicated at will: every copy contains the full history, which makes it, by construction, a resilient arrangement.
The commit
A dated, signed and annotated change. It is the basic unit of the history, and its quality depends entirely on the message that goes with it. “Miscellaneous fixes” is worth nothing; “Fix shipping cost calculation for Corsica” is worth gold six months later.
The branch
A parallel working copy where you prepare a change without touching the live site. You can open ten of them, abandon them, come back to them. The public site, meanwhile, does not move.
The pull request
The moment you propose folding a change in. This is where the review sits: a second pair of eyes, automated tests, an explicit sign-off. Nothing reaches the site without passing through that gate.
Git and GitHub
Git is the tool that manages the history, on your machine. GitHub is the place where that history is hosted, shared and discussed. You can use Git without GitHub, and swap GitHub for GitLab, Bitbucket or an in-house server without changing anything else.
What it changes day to day
The difference is measured in time, and it is dramatic. Tracing the origin of a fault on a site with no history is half a day of investigation and guesswork. With a clean history, it is three minutes:
git log --oneline -10 -- wp-content/themes/my-theme/
git show 4f2a91c
git revert 4f2a91cThe last command deserves an explanation, because for a business owner it is the heart of the matter. git revert erases nothing and does not turn back the clock: it adds a new commit that precisely cancels the effects of a past change, leaving intact everything done since. It is the exact opposite of restoring a backup, which drags the whole site backwards and sacrifices the recent data.
When you do not know which change introduced the fault, automatic bisection settles the question in a handful of tries, even across several hundred commits:
git bisect start
git bisect bad # the current version is broken
git bisect good v1.4.0 # this version workedThis mechanism makes possible what no backup can: undoing a decision without undoing the week.
From the repository to the live site: automated deployment
The chain is always the same: a committed change triggers automatic checks, then a release to the staging site, then, after a human sign-off, to the real one. Two guarantees follow, reproducibility and traceability: every release is identical to the last and leaves a record anyone can consult.
On GitHub, that chain is written in a file kept in the repository itself. Here is the skeleton of a WordPress theme deployment, deliberately minimal:
name: Theme deployment
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- name: PHP syntax check
run: find wp-content/themes/my-theme -name "*.php" -print0 | xargs -0 -n1 php -l
- name: Upload to the server
run: rsync -az --delete wp-content/themes/my-theme/ \
deploy@$SERVER:/var/www/site/wp-content/themes/my-theme/The order of the steps is not decorative: the syntax check runs before the upload, which is enough to stop an invalid PHP file from going live, the cause of a good third of white screens. As for cost, runs are free for public repositories, and a free account has 2,000 minutes a month for its private ones, 3,000 for a Pro account or a team. A theme deployment uses one to two minutes: the limit will never be an issue for a brochure site.
One honest caveat: not everything goes into the repository. The database and the files uploaded by the client live elsewhere and follow another cycle. That is precisely why a repository never excuses you from a tested backup policy.
What if my site runs on WordPress?
The question is a fair one, because WordPress was designed to be edited from its dashboard. The realistic scope is this:
| In the repository | Outside the repository |
|---|---|
| The theme or child theme | The database |
| Custom-built plugins | The uploads folder |
| The list of plugins and their versions | Configuration files that contain passwords |
| Deployment scripts and the integration pipeline | Caches and temporary files |
The ignore file is worth writing properly once, including only what is genuinely yours:
/*
!/wp-content/
/wp-content/*
!/wp-content/themes/
/wp-content/themes/*
!/wp-content/themes/my-theme/
!/wp-content/plugins/my-custom-plugin/
wp-config.php
*.logThe arrangement that works comes in three pieces: the repository for the code, a staging site for testing, backups for the data. It is the same trio that lets you roll back an update that broke the site without drama, and that takes the fear out of what happens when maintenance is neglected.
The awkward question: who owns the code
Here is the part that rarely gets said out loud. A repository hosted on your provider’s account, with you as a mere guest, protects you from nothing: the day the relationship ends, the access ends with it. A repository hosted on your organization’s account, with the provider invited as a collaborator, changes the balance of power completely. It is the same difference as between a domain registered in your name and a domain registered in the agency’s.
Four requirements to set down in writing, before the project begins:
- The repository belongs to your organization; the provider is invited into it.
- The deployment procedure is documented in the repository, in plain language, and reproducible by a third party.
- No secret is stored in the code: passwords and keys live in a vault and are referenced through variables.
- The project introduces no dependency on a closed tool you could not take over.
A serious provider will accept all four without argument, because they cost nothing. Any reluctance on the first will tell you a great deal, and belongs with the questions to ask before signing that we list in our guide on how to choose a web agency. It is also what lets you keep control of your site when you switch providers.
Our position: should everything be versioned?
No, and to claim otherwise would be dishonest. For a simple brochure site, managed solely by its owner through the dashboard, without a line of custom code, a well-run backup policy covers the need. Adding a repository would only add one more constraint.
Three criteria tip the decision, and one is enough: there is custom code, an in-house theme or plugin; several people work on the site; the site carries transactions or changes every month. In those cases, the absence of a repository is no longer a simplification, it is a risk that someone will end up paying for.
Our practice is simple and admits no exception: every custom project starts with a repository opened in the client’s name from day one, a staging site and automated deployment. When we take over an existing site, bringing it under version control is the first job, before the fixes themselves, because it makes everything else reversible. That is what our takeover and repair service for existing sites covers. To go further on the reference tools, the book Pro Git and the GitHub documentation both exist in French, and those are the editions linked here.
Frequently asked questions
Do I need to learn Git as a business owner?
No. You only need to insist that your site benefits from it, that the repository is opened in your name and that you are its owner. Being able to read a dated list of changes is more than enough.
Does a repository replace backups?
No, and this is the most common confusion. The repository protects the code; backups protect the data. An immaculate repository will never give you back lost orders or lost photos.
Is GitHub suitable for a confidential project?
Yes: private repositories exist on every account, free ones included. Confidentiality depends above all on how access is managed, and on never storing passwords there in plain text.
Can a repository be set up on an existing site?
Yes. It is often the first job of a site takeover: you collect the code in place, initialize it in a repository, and at last you have a stable point of comparison.
A site without a history is a site whose future nobody can vouch for. Version control makes it neither prettier nor faster: it makes it repairable, transferable and able to evolve. If your site is already in production, start with the simplest question: ask where its code lives, and in whose name.
Also worth reading: Astro vs WordPress: which foundation for your next site
Talk to us about a versioned projectTake back control of an existing site
