GitOps is an operational model that uses Git as the single source of truth for declarative infrastructure and application deployments, making every change auditable and reversible.
GitOps stores the desired system state in Git and uses automation to continuously reconcile the real environment toward that state. Changes go through pull requests, reviews, and approvals instead of direct console access or manual kubectl commands.
That Git-native workflow replaces imperative operations with declarative intent. Instead of logging into servers and running commands, operators change files in a repository. An automated pipeline detects the drift and applies the new state. The result is faster deployments, easier rollbacks, and an immutable audit trail without additional tooling.
Think of it like this. Think of a restaurant where every menu change must be proposed as a document, reviewed by the head chef, and only then printed and distributed to the kitchen. No waiter rewrites the recipe on the fly.
The desired state is defined in Git using declarative manifests. A GitOps agent continuously compares the Git state to the live cluster state. When they differ, the agent applies the Git version as the source of truth. Alerts fire when reconciliation fails or manual changes are detected outside Git.
"GitOps is a product." It is a workflow that some products implement, not a single tool. "Everything must be in Git." Secrets and mutable objects often need separate handling with encryption or external secret stores. "GitOps replaces CI/CD." It extends CI/CD by shifting deployment authority from scripts to Git state.
Strong auditability, reproducibility, and rollback semantics, but adds Git permission complexity and eventual-consistency delays. Works best with declarative infrastructure and Kubernetes; harder for legacy imperative systems without adaptation.