In your first week on an operations team, you will hear a sentence like “the reconciler will pick it up” and discover that everyone nods except you. This primer exists so that the nodding starts sooner. GitOps, the practice those sentences orbit, is easier than its vocabulary suggests: it is a way of running systems where humans describe the desired outcome in a shared file, and polite software makes reality agree with the description. Everything else — the agents, the syncs, the drift — is vocabulary for parts of that one arrangement. Let us build the vocabulary from something you already own: a wall thermostat.
The thermostat that quietly explains GitOps
A thermostat holds three roles, and each has a twin in GitOps. The number you dial in — twenty-two degrees, say — is the declared temperature: a statement of what you want, not a series of instructions about fans and valves. In our world, that statement is a commit: a proposed file change, reviewed and accepted into a shared repository. The room itself, drifting warm in the afternoon and cool at midnight, is the live system — the cluster where your applications run. And the thermostat box on the wall, measuring and correcting without complaint, is the reconciler: software such as Argo CD or Flux, watching the record and nudging the room back to the dialled number. The elegance of the arrangement is what it removes. Nobody runs upstairs every twenty minutes to check the room and open a window. You do not do that with servers either, once a reconciler is on the wall. Operations people who have spent years doing the upstairs-checking routine will find kindred analysis in the study of reducing toil through SRE automation — same disease, different name.
How a change actually travels through GitOps
Suppose your team needs a new version of the payments service deployed. In a GitOps setup the journey is short and entirely visible:
- You edit the declaration — the file that says which version of payments should run — and open a pull request, which is simply a formal proposal showing exactly what you changed.
- A colleague reviews the proposal. This is the quality gate, and it applies to everyone, including senior engineers and, increasingly, automated assistants.
- The proposal is merged. Nothing has happened to production yet; only the record has moved.
- The reconciler notices — either a webhook tapped it or its regular poll came round — and compares the record against the live cluster.
- It applies the difference: new version rolled out, old one retired, anything the record no longer mentions tidied away.
- It reports status, so the team sees a green line where there used to be a question mark.
Two things are worth pausing on. First, the continuous-integration system has not been fired; it still builds the image and runs the tests. GitOps takes over only at the delivery step. Second, at no point did anyone log into a production machine. That absence is not a restriction imposed by a grumpy platform team; it is the design working.
The four ideas behind GitOps
An industry consensus document — the OpenGitOps principles — spells out what separates genuine GitOps from lookalikes, and beginners deserve the short version. The goal must be declared: files that describe the outcome, not scripts that describe the journey. The description must live somewhere versioned and unchangeable in hindsight, so that last Tuesday’s truth can be read today and restored tomorrow. The fetching must be done by an agent that pulls — the system goes and collects its instructions rather than waiting for an outside process to push commands at it, which keeps the keys inside the boundary. And the matching must be continuous, a loop rather than a one-time event; a check that runs every couple of minutes qualifies, while a script that fires once at deploy time does not. A pipeline job that merely applies whatever it just built manages to satisfy, at best, two of those four ideas. It is a useful test to keep in your pocket when someone shows you a slide with the word GitOps on it.
A mini-glossary for your first GitOps week
Here are the words you will meet, in roughly the order you will meet them:
- Repository — the shared, version-controlled home of every declaration. The single source of what should exist.
- Desired state — the content of those declarations: versions, counts, settings, rules.
- Reconciler — the agent (Argo CD and Flux are the household names) that watches the repository and adjusts the live system to match.
- Sync — the act of bringing reality level with the record. Can be automatic, or a button a human presses while trust is still growing.
- Drift — any difference between record and reality. Sometimes an accident; sometimes an autoscaler doing its job; always visible now.
- Prune — the reconciler removing something the record no longer declares. Powerful, therefore guarded with rules about what may never be pruned.
- Webhook — a doorbell that lets a merge notify the reconciler immediately, instead of waiting for the next poll.
- Secret — a password or key. Kept encrypted and referenced, never pasted into the repository in plain text.
With those eight terms, most team conversations about the practice become readable, and the documentation stops feeling like a cipher. Three questions come up in almost every beginner’s first month, so here are the short answers. Is this only for enormous fleets? No — a two-service project benefits from the same record-keeping, at proportionally smaller cost. Should the existing CI system be switched off? Absolutely not; it keeps building and testing, and hands over only when the artifact is ready to ship. What about the database? Its structure can be declared, but its contents belong to backups, not to the repository — a boundary that protects sensitive data and keeps the record light enough to review.
When something goes wrong — and something will
Beginners often assume the automation turns incidents into catastrophes. The opposite is the norm, provided the team has one rehearsed move: the ability to pause. Reconcilers can be suspended, letting a responder make careful manual changes during an emergency without an obedient machine undoing them mid-fix. Afterwards, the manual changes are written back through pull requests so the record and reality meet again. Teams that practise this once stop fearing it — and readers who want the wider discipline around those moments will find it in how SRE practices and automation reshape incident management. The pattern is the same at every scale of operations, from a single service to the machine-learning pipelines described in the essential role of MLOps in machine learning success: declare the goal, let software handle repetition, keep humans on judgement.
Your first week with GitOps, in practical terms
Do not begin by converting production. Begin by reading a real reference — a beginner-friendly GitOps guide with labs and checklists will ground the vocabulary this primer introduced. Then pick a service nobody will cry over, write its declaration, and install a reconciler with syncs set to manual, watching what it notices before letting it act. The first drift alert is a small ceremony worth celebrating: it means the record, the room, and the box on the wall are all talking to each other. From there, growth is gradual and mostly procedural — more services declared, more reviews, fewer midnight logins, and one day you will catch yourself saying “the reconciler will pick it up” to a newcomer, nodding included.