GitOps is not "using Git for YAML." It is an operating model for continuously reconciling a running system toward versioned desired state.

Engineer / automation
       ↓
Pull request
       ↓
Versioned desired state in Git
       ↓
GitOps controller pulls + renders
       ↓
Kubernetes API
       ↓
Live cluster state
       ↑
continuous comparison / reconciliation

Four ideas to internalize

1. Desired state is declarative. Git describes what should exist, not a long imperative deployment script.
2. Desired state is versioned and immutable in history. A commit gives you an auditable point-in-time configuration.
3. Software agents pull and apply. The delivery controller runs close to the cluster and fetches desired state; CI does not need permanent cluster credentials just to deploy.
4. Drift is continuously reconciled. The system compares live state with Git and can report or correct differences.

GitOps is not CI

CI answers questions such as:

Does the code compile?
Do tests pass?
Can we build a container image?
Can we scan and attest the artifact?

GitOps CD answers:

Which artifact should this environment run?
What Kubernetes resources should exist?
Does live state match Git?
Should drift be corrected automatically?

A mature flow often looks like:

Code repo
  ↓ CI
immutable image: sha256:...
  ↓
configuration repo update
  ↓
Argo CD reconciliation
  ↓
cluster

Why SREs care

GitOps improves evidence during incidents. Instead of asking "who ran kubectl?", you can ask:

What commit changed desired state?
Who approved it?
When did Argo CD reconcile it?
What was different from live state?
Can we return to a known-good commit?