{"id":11607,"date":"2026-10-19T07:30:00","date_gmt":"2026-10-19T07:30:00","guid":{"rendered":"https:\/\/www.cotocus.com\/blog\/?p=11607"},"modified":"2026-10-19T07:30:00","modified_gmt":"2026-10-19T07:30:00","slug":"gitops-beginner-glossary-primer","status":"publish","type":"post","link":"https:\/\/www.cotocus.com\/blog\/gitops-beginner-glossary-primer\/","title":{"rendered":"GitOps for Beginners: A Plain Guide and Glossary"},"content":{"rendered":"

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 \u2014 the agents, the syncs, the drift \u2014 is vocabulary for parts of that one arrangement. Let us build the vocabulary from something you already own: a wall thermostat.<\/p>\n

The thermostat that quietly explains GitOps<\/h2>\n

A thermostat holds three roles, and each has a twin in GitOps. The number you dial in \u2014 twenty-two degrees, say \u2014 is the declared<\/em> 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 \u2014 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<\/a> \u2014 same disease, different name.<\/p>\n

How a change actually travels through GitOps<\/h2>\n

Suppose your team needs a new version of the payments service deployed. In a GitOps setup the journey is short and entirely visible:<\/p>\n

    \n
  1. You edit the declaration \u2014 the file that says which version of payments should run \u2014 and open a pull request, which is simply a formal proposal showing exactly what you changed.<\/li>\n
  2. A colleague reviews the proposal. This is the quality gate, and it applies to everyone, including senior engineers and, increasingly, automated assistants.<\/li>\n
  3. The proposal is merged. Nothing has happened to production yet; only the record has moved.<\/li>\n
  4. The reconciler notices \u2014 either a webhook tapped it or its regular poll came round \u2014 and compares the record against the live cluster.<\/li>\n
  5. It applies the difference: new version rolled out, old one retired, anything the record no longer mentions tidied away.<\/li>\n
  6. It reports status, so the team sees a green line where there used to be a question mark.<\/li>\n<\/ol>\n

    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.<\/p>\n

    The four ideas behind GitOps<\/h2>\n

    An industry consensus document \u2014 the OpenGitOps principles \u2014 spells out what separates genuine GitOps from lookalikes, and beginners deserve the short version. The goal must be declared<\/strong>: files that describe the outcome, not scripts that describe the journey. The description must live somewhere versioned and unchangeable in hindsight<\/strong>, so that last Tuesday’s truth can be read today and restored tomorrow. The fetching must be done by an agent that pulls<\/strong> \u2014 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<\/strong>, 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.<\/p>\n

    A mini-glossary for your first GitOps week<\/h2>\n

    Here are the words you will meet, in roughly the order you will meet them:<\/p>\n