You've adopted infrastructure as code. Terraform lives in a repo. Kubernetes manifests live in a repo. But how do those files actually become running infrastructure? If the answer involves a human running terraform apply from their laptop, or a CI job with cluster credentials pushing changes, you don't have GitOps — you have "infrastructure files that happen to live in Git."

The core idea: the Git repository is the only source of truth for what should be running. An agent inside the target environment continuously pulls from Git and reconciles reality to match. Changes flow one way: commit → merge → agent notices → cluster converges. No human ever runs kubectl apply.

Push-based CI/CD vs pull-based GitOps:

• Push model: CI pipeline has cluster credentials and shoves changes in. If someone edits the cluster directly, drift is invisible until the next deploy.
• Pull model: An in-cluster agent (Flux, ArgoCD) polls Git every 30 seconds, diffs against live state, and reconciles. Manual changes get reverted automatically. Credentials never leave the cluster.

Real-world example: A payments team runs 40 microservices across three Kubernetes clusters (dev, staging, prod). Previously, deploys were "merge to main, CI runs helm upgrade." An engineer once ran kubectl edit in prod to bump a memory limit during an incident — that change survived for six weeks until the next deploy silently reverted it, causing an OOM outage at 3 AM. After moving to ArgoCD, the manifest repo holds the desired state per environment. The 3 AM engineer's kubectl edit now gets reverted in 30 seconds and shows up as drift in the dashboard — forcing the fix through a PR instead of a ghost edit.

What you get for free:

• Audit trail: git log tells you exactly who changed what and when. No separate deploy log needed.
• Rollback: git revert. That's it. The agent notices and rolls back.
• Disaster recovery: Lose the cluster? Point the agent at the repo and it rebuilds everything.
• Drift detection: Anything not in Git is either reverted or flagged.

Rule of thumb: If your reconciliation loop is slower than 60 seconds, engineers will bypass it during incidents. If it's faster than 10 seconds, it'll spam your API server. Target a 30-second sync interval with immediate reconciliation on webhook.

Where it breaks: Secrets don't belong in Git — use Sealed Secrets, SOPS, or an external secrets operator. Also, GitOps assumes declarative state; imperative operations (database migrations, one-time data fixes) still need a separate mechanism. Don't try to force kubectl exec workflows through Git.