What GitOps is · Prasanta Kumar Behera

GitOps in plain terms: the desired state of every environment lives in Git, and an agent inside each cluster continuously pulls it and makes reality match. The four principles, why pulling beats pushing for clusters, and what changes for developers and operators.

An agent in the cluster watches Git, compares desired and live state, and reconciles the difference.

The idea in one sentence

Everything that should run in an environment is declared in Git, and software in the environment keeps it that way.

Deploying becomes a Git change (usually a pull request); rolling back becomes reverting a commit; auditing becomes reading Git history.

A thermostat. You set the temperature you want (Git). The thermostat keeps checking the room (the cluster) and switches the heating on or off until the room matches. If someone opens a window, it notices and corrects. You never walk over and adjust the radiator by hand.

The four principles (OpenGitOps)

Principle	Means	In practice
Declarative	The desired state is described, not scripted	Kubernetes manifests, Helm values, Kustomize overlays
Versioned and immutable	Desired state is stored with full history	Git: every change has an author, a review and a reason
Pulled automatically	Agents fetch the desired state themselves	Argo CD or Flux inside the cluster pull from Git
Continuously reconciled	Agents keep comparing and correcting	Drift is detected, reported and (optionally) reverted

Push versus pull

	Push (CI runs `kubectl apply` / `helm upgrade`)	Pull (GitOps agent in the cluster)
Credentials	CI holds cluster-admin credentials for every cluster	Only the cluster holds its own credentials; CI needs Git access
Network	CI must reach every cluster API	Cluster reaches out to Git (works behind firewalls, at edge sites)
Drift	Only noticed at the next deploy, if ever	Detected continuously, optionally self-healed
Many clusters	CI must loop over all of them	Each cluster pulls its own state
Audit	Pipeline logs	Git history + agent events

CI still matters: it builds, tests and publishes artifacts, then updates Git. The agent takes it from there.

developer ──PR──► app repo ──CI──► image in registry
                                   └─► PR: bump image in config repo ──merge──► config repo
                                                                                   ▲
                                              cluster: GitOps agent ──pulls & applies┘

What changes for people

Developers release by merging a pull request, see deployment status in the GitOps UI, and roll back with git revert.
Operators stop running ad-hoc commands in production; emergency fixes also go through Git (fast-tracked, but recorded).
Security and audit get a complete, reviewed history of every change to every environment for free.
Break-glass still exists, but a manual change is either reverted by the agent or must be copied back into Git immediately.

What GitOps doesn't solve alone

Secrets: they can't sit in Git as plain text (lesson 04).
Promotion between environments: needs a deliberate design (lesson 03).
Databases and state: GitOps deploys the app; schema migrations and data need their own process (often a hook or a job).
Things outside Kubernetes: cloud resources are usually Terraform (or Crossplane/ACK for a GitOps-style approach).

Try it: see reconciliation

On a kind cluster, install Argo CD (see "Argo CD — Level by Level", lesson 02) or Flux.
Point it at a Git repository with one Deployment and let it sync.
kubectl scale deploy/<name> --replicas=5 and watch it return to the Git value (with self-heal on) or show OutOfSync (without).
Change replicas in Git, push, and watch the cluster follow.

Recap

GitOps: desired state in Git, agents pull and reconcile it continuously.
Four principles: declarative, versioned & immutable, pulled automatically, continuously reconciled.
Pull beats push for clusters: no cluster credentials in CI, drift detection, scales to many clusters.
CI builds and updates Git; secrets, promotion and state need deliberate design.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.