GitOps is a way of operating infrastructure and applications where Git is the single source of truth for what should be running, and an automated agent continuously reconciles the actual state of the system to match it. The term was coined by Weaveworks in 2017, but the underlying idea — declarative desired state, version control, automated reconciliation — predates it. What GitOps added was a specific set of practices and a set of tools that made the pattern practical for Kubernetes.
This guide covers what GitOps actually means (not just the marketing definition), how the reconciliation loop works, how ArgoCD and Flux compare, and where GitOps genuinely helps versus where it adds unnecessary complexity.
The four GitOps principles
The OpenGitOps project (a CNCF working group) defines GitOps around four principles:
1. Declarative. The desired state of the entire system is expressed declaratively. This means Kubernetes YAML manifests, Helm chart values, Kustomize overlays — not imperative scripts. "Apply these manifests" rather than "run these commands." The advantage: the desired state can be stored, diffed, and audited.
