If you have ever asked a developer how their work is organized and gotten back a barrage of acronyms (Git, GitHub, repos, branches, commits, pull requests), you have run into one of the most universal pieces of software-development infrastructure in 2026. Every site I build lives in a Git repository on GitHub, and the repository is one of the quiet workhorses behind everything else. This post is the version of that conversation I want every client to have read.
The short version: Git is a way of tracking every change to a set of files, with a permanent timestamped log. GitHub is the place where the Git repository lives, with a friendly web interface on top. Together they mean every line of code that has ever existed on your site is recoverable, and every change can be inspected, reverted, or audited at any time.
What a "repository" actually is
A Git repository (often shortened to "repo") is a folder of files with a hidden tracking layer underneath. The folder itself looks normal — just files and subfolders — but Git keeps a complete history of every change ever made to those files. Every save, every deletion, every line modified, every new file added.
That history is permanent. Files deleted from the repository can be recovered from any past version. A change made today can be inspected against the version from a year ago, with the differences highlighted line by line. The repository is, in effect, a complete time machine for the codebase.
For sites I build, the repository contains everything that produces the site: the HTML templates, the Markdown content, the CSS, the JavaScript, the configuration files, the build scripts, the deployment instructions. Plus images and other assets that ship with the site. If the entire repository were copied to a new machine, the site could be rebuilt from scratch in two minutes.
What "commits" are
Every change to the repository is grouped into a "commit." A commit is a labeled snapshot: a description of what changed, who made the change, and when. A typical commit message reads something like "Add hours of operation to contact page" or "Fix typo in service-area description for Boulder."
The commit history reads like a project log. Six months after launch, you can scroll through the commits and see exactly what changed on which day. Six years after launch, the log is still there, with every modification annotated.
For most clients, the commit log is invisible — they email me with content updates, I make the change, the commit lands, the site updates. The client sees the result; the log records the work. But the log is available to the client at any time, and on the rare occasion when something needs auditing ("who removed the Saturday hours from the contact page?"), the answer is one search in the commit log.
What "deploy on push" means
The connection between the GitHub repository and the live website is automatic. Every time I push a commit to the repository's main branch, Cloudflare Pages detects the push within a few seconds, pulls the new code, runs the build pipeline, and publishes the result to the live website. The whole flow takes 30 seconds to two minutes.
This is the modern small-business-website workflow. There is no FTP, no manual file uploading, no "remember to copy the changed files to the server." A change is committed once, and the deployment is automatic.
The advantage from a client perspective is that updates are fast and reliable. The advantage from my perspective is that I can never forget to deploy a change, and I can never accidentally upload the wrong files.
Why this matters for a small business
The repository system produces three concrete client-facing benefits.
Rollback to any past version is fast. If a change introduces a problem (a copy edit produces a broken layout, a new feature has an unexpected side effect), reverting to the previous version is one Git command and one redeploy. The site is back to its previous state within minutes, with no data loss.
Audit trail is permanent. Every word on the website was added at a specific time by a specific person. If a price was changed by mistake or a service description got accidentally edited, the change is recoverable and the timeline is recoverable.
The site is portable. If the client ever moves to a different developer, the entire site (and its history) is in the repository. The new developer clones the repository, runs the build, and continues. There is no "the old developer needs to give us access to the proprietary platform" step.
Where the repository lives
For sites I build, the repository is hosted on GitHub under my own organization, with the client granted appropriate access. I do this for two reasons:
Operational continuity. Hosting the repository in my account means I can make changes without coordinating credentials with the client. I can deploy fixes at midnight on a Saturday during a storm-season traffic spike without waiting on the client to grant access.
Backup and continuity. The repository is automatically backed up by GitHub's infrastructure, with version history preserved indefinitely. Every commit is replicated across GitHub's data centers within seconds of being pushed.
If a client wants their own copy of the repository (for backup, for archival, or because they want to engage another developer), I provide a clone at any point during or after the engagement. The repository is small (typically a few hundred KB plus the image assets), and a complete copy fits on any modern device.
What the client typically interacts with
For most clients, the answer is "nothing directly." The repository is the developer's tool, not the client's tool. Updates flow through email or the content-update form; I make the changes in the repository; the changes go live; the client sees the result.
For clients who do want to look at the repository, GitHub provides a clean web interface. They can browse the file tree, read the commit log, search for specific files or terms, and view the differences between any two versions. No technical knowledge required to read; some technical knowledge required to write changes.
For clients with a developer on staff or a tech-comfortable team, the repository becomes a collaboration surface. The team member can review my changes before they go live, propose edits via pull requests, or even handle small content updates themselves. This is rare on small-business engagements but supported on the rare occasions when it comes up.
What this skips
By using GitHub for version control, I get to skip a category of small-business-website pain that older workflows produce:
- No "the developer accidentally overwrote my logo and now it is gone forever."
- No "we hired someone to update the site and they broke something we cannot identify."
- No "the previous version of this page had a paragraph I wanted to keep but I deleted it."
- No "I have no idea what changed between last week and this week."
The repository solves all four of these by keeping every version recoverable.
If your current site has no version control
Most small-business websites built before 2018 have no version-control history. The site exists as a snapshot on a server; previous versions are gone forever; the developer has no log of changes; rolling back is rebuilding.
For sites I build, version control is part of the standard plan from day one. For sites I do not build, retroactively adding version control is straightforward but the historical record cannot be reconstructed (the past is just gone). Going forward, every change is logged, but pre-engagement history is not recoverable.
Worth being clear: most small businesses never need the version history. The site runs, the changes happen, and the past versions are not consulted. But on the rare occasion when something does go wrong, having the history is the difference between a 5-minute rollback and a 5-day rebuild.
Every change to your site is logged forever.
Every site I build is stored in a Git repository, with a permanent history of every change. Rollback to any past version is a few minutes of work, and you can always see exactly what changed and when.