Strip away the terminology and GitOps is one sentence: the intended configuration of a system lives in version control, and an agent continuously reconciles the running system against it.
That is it. Everything else is tooling.
Why it matters more here than it did before
Traditional infrastructure was configured by people performing actions. The record of what was done lived in change tickets, wiki pages, and memory. Drift was normal and invisible.
Kubernetes is already declarative: you submit a description of desired state and controllers reconcile toward it. GitOps extends that one step further out, so the description itself is versioned rather than typed into a terminal.
The result is a system where the question “what is supposed to be running” has a definite answer that anyone can read, and where the difference between intention and reality is detectable rather than assumed.
What you actually get
A real audit trail. Every change is a commit with an author, a timestamp, and a review. This is better than any change management system I have used, and it is a by-product rather than an additional process.
Reproducibility. Rebuilding a cluster means pointing the agent at the repository. Whether this fully works is a good test of whether you are actually doing it.
Drift detection. The agent knows when reality differs from the declaration, and can either alert or correct. Manual changes made during an incident get surfaced instead of forgotten.
Rollback that means something. Revert the commit. The agent converges back. This is genuinely how it works for configuration, and it is not how anything else in infrastructure works.
What it costs
Secrets get harder. You cannot commit credentials to a repository. You need sealed secrets, an external secret store with a controller, or an operator that pulls from a vault. Every team hits this in week one and it is the most common place the approach gets abandoned.
Decide the secret strategy before you start, not after.
Emergency changes become awkward. During an incident the instinct is to fix it directly. If you do, the agent may revert your fix. Teams need an agreed break-glass procedure: pause reconciliation, fix, then commit the fix properly.
Without that agreement you get a culture where people disable the agent during incidents and forget to re-enable it, which is worse than not having it.
Repository structure is a real design decision. One repo or many, how environments are separated, how you avoid copying the same manifest four times with three values changed. Get this wrong and the repository becomes as hard to reason about as the thing it describes.
Where I would start
Not with everything. Start with one cluster’s platform configuration: namespaces, quotas, network policies, operator subscriptions. These change slowly, are easy to describe, and are exactly the things that drift invisibly.
Get that working, live with it for a quarter, then extend to applications if it is earning its keep.
The infrastructure parallel
If you have ever maintained switch configurations in version control and pushed them out, you have done this. Same idea, better tooling, and a system on the other end designed to be driven this way.
The instinct that made you keep those configs in a repository is the correct instinct. GitOps is that instinct with a reconciliation loop attached.