If you've ever ended up with a folder containing website-final.html, website-final-v2.html, website-final-ACTUAL.html and website-final-use-this-one.html, you've already felt the problem Git solves. You were trying to keep a history of changes and a way back to a known-good version, just doing it by hand, badly. Git does that properly, and it isn't only for software developers.
What Git actually is
Git is a version control system. In plain terms, it keeps a complete, timestamped history of every saved change to a set of files, lets you see exactly what changed between any two points, and lets you roll back to any previous state, perfectly, with nothing lost. Think of it as an infinite, surgical undo history for a whole folder, that survives across devices and never forgets.
It was built for source code, which is why most explanations assume you're a programmer. But Git doesn't care what's in the files. It works just as well for:
- Website files, HTML, CSS, and content, with a clean history of every change and an instant way back if an edit breaks something.
- Server and application configuration, so you can see exactly what changed, and when, the next time "it stopped working after someone edited the config."
- Documents and writing, contracts, policies, documentation, anything where the history of changes matters and "which version is current?" is a real question.
- Infrastructure definitions, increasingly, the files that describe your systems live in Git too.
The handful of concepts you actually need
Git has a lot of advanced machinery, but day-to-day use rests on a few ideas:
Repository ("repo")
A folder that Git is tracking. It contains your files plus a hidden history of every change ever made to them. You "initialise" a repo once, and from then on Git watches that folder.
Commit
A saved snapshot of your files at a moment in time, with a short message describing what changed ("fixed pricing on services page"). This is the single most important concept: each commit is a permanent, named point in history you can always return to. You commit whenever you've reached a state worth being able to get back to.
Diff
The exact difference between two versions: which lines were added, removed, or changed. When something breaks, a diff shows you precisely what changed to cause it, instead of guessing.
Remote
A copy of the repository hosted elsewhere, on a service like GitHub or GitLab, or a self-hosted server. You "push" your commits up to it and "pull" others' changes down. This is what makes Git a backup, a sync mechanism, and a collaboration tool all at once: your full history lives in more than one place.
Branch
A parallel line of work. You can split off a branch to try something risky, and if it works, merge it back; if it doesn't, throw it away, with your main version untouched the whole time. For simple solo use you can mostly ignore branches, but it's why teams can work on the same project without standing on each other.
The mental model that makes it click: you work on your files normally, and at sensible points you take a labelled snapshot (a commit). Git remembers every snapshot forever and can show you the difference between any two, or restore any one of them. Everything else, remotes, branches, the scary-looking commands, is built on that one simple idea.
Why it's worth the initial friction
Git genuinely does have a learning curve, and the command-line version can feel hostile at first. So it's fair to ask whether it's worth it for non-code work. The honest answer: for anything where the history of changes matters, yes, and you don't have to touch the command line to get the benefit.
- Nothing is ever truly lost. Every version you committed is recoverable, forever. The "which file is the real one" problem disappears.
- You can always answer "what changed?", and "when?", and "what did it look like before?" This alone pays for itself the first time something breaks.
- It's a backup and a sync in one. With a remote, your full history exists in multiple places automatically.
- Graphical tools exist. Desktop apps and the interfaces built into editors let you commit, view history, and roll back with buttons rather than commands, a gentle on-ramp while the concepts sink in.
A realistic starting point: you don't need to learn all of Git to benefit from it. Learn three things, how to commit (take a snapshot), how to view history and diffs (see what changed), and how to push to a remote (keep a copy elsewhere), and you've already solved the version-chaos and safe-history problems that affect everyone, developer or not. The rest can wait until you need it.
Frequently asked questions
Do I need to be a programmer to use Git?
No. Git tracks changes to any files, not just code. It's genuinely useful for website files, server configs, documents, and anything where keeping a reliable history and being able to roll back matters.
What's the difference between Git and GitHub?
Git is the version control system that runs on your own machine and keeps the history. GitHub (and GitLab, and others) is a hosting service where you can keep a remote copy of a Git repository: for backup, syncing across devices, and collaboration. You can use Git with no hosting service at all.
Do I have to use the command line?
No. While many people use Git from the command line, there are graphical desktop applications and built-in editor interfaces that let you commit, view history, and roll back with buttons. They're a good way to start while you learn the concepts.
What's a commit, in simple terms?
A commit is a saved snapshot of your files at a point in time, with a short message describing what changed. Git keeps every commit permanently, so you can always see what any version looked like or return to it.
Wondering whether version control would help how you manage your site or systems? Get in touch, happy to talk through whether it's worth setting up for your situation.
Get in touch →