Strip away the conference-slide vocabulary and GitOps is a simple arrangement: you keep a written description of how your systems should be set up, you store that description somewhere that remembers every edit, and you let a small program compare the description against reality all day long, fixing whatever has wandered. That is the whole idea. Everything else — the tools, the jargon, the job titles — is detail hung on that frame. This article walks through the idea the way a patient cook would explain a kitchen, because kitchens turned out to be the clearest place to see it.

GitOps in one sentence, then in three

One sentence: the written record is the truth, and software keeps reality agreed with the record. Three sentences, with the machinery visible: your setup lives as files in a repository where nothing is ever quietly overwritten; an agent reads those files on a schedule and inspects the running systems; whenever the two disagree, the agent either corrects the systems or raises the difference, according to rules you chose in advance. Notice who does what. People propose and review changes. The program carries them out and polices the gaps between. Neither does the other’s job.

The kitchen that never loses a recipe

Picture a restaurant whose recipes exist in one master book, kept locked, where every amendment is dated and signed by whoever proposed it. Nobody cooks from memory. Copies float around the kitchen, of course, and copies wander: a page gets splashed, someone scribbles a note, a shelf copy goes missing. So the head chef walks the line each hour with the master book open, checking the working copies against it. Splashed page? Reprinted. Unauthorised scribble? Erased. Missing? Replaced. The book is GitOps’s repository; the hourly walk is reconciliation; the head chef is the agent. And a reader who has ever thought about why a family recipe deserves to be preserved already understands the deepest reason the master book stays locked: records outlive the people who made them, but only if the records themselves are protected from casual amendment.

The four rules GitOps insists on

An industry group called OpenGitOps published four principles, and versions of them now appear in standards documents. In ordinary words:

• Say what you want, not what to do. The record describes the end state — “two copies of the ordering service, this version, these limits” — rather than a list of steps.
• Keep that record where history survives. Every edit is a new, dated revision; yesterday’s version can always be read or restored, and no entry is quietly rewritten.
• Let the machine come and collect. The agent fetches the record itself and acts on it; systems are not pushed at from outside by whoever holds the keys.
• Never stop checking. Matching is a loop, not an event. A check every few minutes counts; a single pass after each deploy does not.

A team that satisfies all four is running the method. A team that satisfies two is running something else with a fashionable name attached, which happens more often than anyone admits. The rules also explain why pilots of this approach so often start small: the loop itself is cheap, but writing a truthful record of an existing, messy system is honest work, and doing it for one service teaches you what doing it for fifty would demand. Start where the record can actually be finished, not where the slogan sounds best.

What GitOps is not

Clearing up the neighbours helps as much as defining the thing itself. Three mix-ups cover most of the confusion.

It is not “just files in a repository”

Storing configuration text in Git is a good habit and nothing more. Without an agent walking the line — comparing, correcting, reporting — there is no method, only storage. The checking loop is the method; the files are its raw material.

It is not a backup

The record describes structure: which services run, at which versions, under which rules. It does not contain the customer rows in your database, the photographs in your uploads folder, or anything else users actually created. When storage fails, the structure can be rebuilt from the record, but the contents come back only from a genuine backup. Serious teams keep both and never let one impersonate the other.

It is not a licence to skip review

The agent executes faithfully, including mistakes. A merge that deletes something important will be carried out with perfect obedience. Human review before the merge stays exactly where it was — the front door every change still has to walk through.

A change, from idea to plate

The working rhythm, end to end, looks like this:

1. Someone proposes a change as a file edit and opens a pull request — a formal “here is my suggestion” complete with the exact difference.
2. A colleague reviews it, asks questions, requests tweaks, and eventually approves.
3. The edit is merged into the record.
4. The agent notices, either because a webhook tapped it on the shoulder or because its regular check came round.
5. It inspects the live systems, writes out the difference between record and reality, and applies what is needed — including removing things the record no longer mentions.
6. It reports the outcome where the team can see it, so nobody has to ask whether the change landed.

Six steps, no logins to production, no “quick fix” applied straight to a server and forgotten. The two tools most often playing the agent’s role are Argo CD and Flux, both mature, both free to run, and both happiest when the record they watch is tidy. Either one will happily report on systems it is not yet allowed to change, which makes the first fortnight of any pilot painless: run the agent in report-only mode, read what it finds, and fix the surprising bits before you grant it permission to act. Every kitchen inspects before it tastes.

Why plain-language GitOps matters beyond software teams

The pattern generalises further than computing, which is why the kitchen frame is not just decoration. Any operation that suffers from undocumented changes — a growing café’s roster of suppliers, a clinic’s equipment logs, a media archive — benefits from the same three-part move: write down the intended state, protect the written record, and automate the comparison between record and reality. Software teams simply got there first because their failures were loud enough to force the issue. And when the time comes to choose tools for the technical version of this discipline, it pays to evaluate them the same careful way you would explore and compare software tools for any other job: by fit and maintenance cost, never by slogan. A thorough next stop is a plain-language GitOps explainer maintained at xOps School, which carries the reference detail — lab exercises, runbooks, and a full tool map — that a short article can only gesture at. Meanwhile, the habit worth stealing today costs nothing: the next time something in your operation changes and nobody can say who changed it, write down what should be true instead of complaining about what is. That sentence, kept and checked, is where the whole method starts — and the crews who treat their records with the care shown by people protecting culinary heritage for the long run tend to find that their systems, like their recipes, still work years later.