Git for non-developers: why your website should live in version control

Version control records every change to your website with who, when and why, and lets any of it be undone. What owning the repository means.

3 minread 676words last updated

The short answer

Git is the system nearly all software in the world is built with. It records every change to a set of files: what changed, who changed it, when, and a short message saying why. It can reproduce the files exactly as they were at any point in the past. A repository is the complete history of your website in one place. For a business, that means four things: nothing is ever lost, every change has a name on it, any change can be undone, and several people can work at once without overwriting each other. Owning the repository, in an account in your company’s name, is what “you own the code” means in practice.

What it gives a business

PropertyWhat it means for you
Complete historyEvery version of every file, forever; a page deleted in 2024 can be brought back in 2027
AttributionEach change has an author, a time and a reason; disputes about who changed what are answered by a lookup
UndoAny change, or any set of changes, can be reverted cleanly; a bad edit is a one-step reversal
Parallel workTwo people, or a person and an automation, work on separate changes without conflict
ReviewChanges are proposed, seen as a difference from the current site, and approved before merging
TriggerA committed change starts the build pipeline: checks, preview, deploy
PortabilityThe whole history moves to a new partner or a new host in minutes

Owning it properly

  1. An organisation account on an established repository host, in the company’s name, on a company email.
  2. Two administrators from your side with two-factor, who log in once a quarter to prove they can.
  3. Your partner as a collaborator, with the access the work needs and no more.
  4. Protection on the main line: changes arrive through reviewed proposals, not direct edits, and the pipeline must pass.
  5. Written into the setup document: where the repository is, who administers it, how a new collaborator is added or removed.

Content in version control

On a static site built with content collections, your pages and articles are files in the same repository as the code. Every edit to a paragraph has the same history, review and undo as a code change, and the same pipeline checks it before it goes live. Editors do not need to know Git; a content editing interface writes the commits for them. The result is a website where no change of any kind is anonymous or irreversible.

What this means for you

You do not need to learn Git. You need your website to live in it, in a repository your company owns, with your partner as a guest. Then every change is recorded, attributable and undoable, the pipeline has something to build from, and leaving a partner is a matter of removing a collaborator rather than negotiating for your own history.

Written by the CivSec S.M.A.R.T team

We build and run websites, software and AI systems for businesses. We write about what we see in that work, in plain language, and we update articles when things change.

Last checked . Spotted something outdated? Tell us.

Frequently asked questions

Do we need to learn Git to own our website?

No. You need to own the account that holds the repository and know how to invite and remove collaborators, which is a web interface. Your partner does the day-to-day work. Owning the repository is like owning the filing cabinet; you do not have to file the papers yourself.

Where should the repository live?

On an established hosting service for repositories, in an organisation account in your company's name, with two-factor and at least two administrators from your side. Your partner is added as a collaborator with the access the work requires. If you leave the partner, you remove them; the history stays with you.

Is the content in the repository too, or only the code?

On a static site with content collections, both: pages, articles and structured data live as files next to the code, so a content change has the same history and undo as a code change. With a separate content system, the content lives there and the repository holds the code and the connection to it.

Sources

  1. Git documentation: Getting started (accessed 2026-09-11)