What Is GitOps? Git as the Source of Truth

Quick answer
GitOps makes a Git repository the single source of truth for what should be running.
A reconciler continuously compares the live system to the Git state and fixes any drift automatically.
Every change goes through a pull request, so infrastructure changes get review, history, and rollback for free.

What is GitOps?

GitOps is an operating model for infrastructure and applications in which a Git repository holds the desired state of a system, and a software agent continuously makes the live system match it. The Git history becomes the audit log, and the pull request becomes the control plane. GitOps was popularized by Weaveworks in 2017 and is now widely used with Kubernetes.

How does GitOps work?

You declare what you want — deployments, config maps, ingress rules — as files in Git. An agent such as Argo CD or Flux watches that repository, compares the files against the live cluster, and applies the difference. There are two common styles: a push model, where a CI pipeline pushes changes, and a pull model, where the agent pulls from Git on a schedule. The pull model is the canonical GitOps pattern because the cluster never needs write access to your repository.

Why does GitOps matter?

GitOps gives infrastructure the same review process as application code. A bad change can be reverted with git revert, and the answer to “why is production different from staging?” is always visible in Git. It also improves security: engineers can deploy without holding direct production credentials, because the agent does the applying.

Where this bites vibecoders
An AI assistant that helps you “deploy to Kubernetes” often writes commands you run by hand: kubectl apply over and over, with drift between what you meant and what is actually running. Without Git as the source of truth, there is no record of who changed what or how to undo it. GitOps is the discipline that turns a pile of one-off applies into a reviewable system.

Where AI coding assistants get this wrong

Producing imperative kubectl commands instead of declarative manifests that a reconciler can enforce.
Leaving plaintext credentials in manifests that would be committed to Git.
Confusing the push model with the pull model and wiring a pipeline to mutate a cluster directly.
Generating manifests that reference container image tags like latest, which defeats the reproducibility GitOps relies on.

Checklist

Store all environment and cluster configuration as files in Git.
Use a reconciler (Argo CD or Flux) rather than manual kubectl apply.
Prefer immutable image tags over latest.
Keep secrets out of Git; use a secret manager and reference it from the manifest.
Practice rollback: revert a change and confirm the reconciler restores the old state.

FAQ

How is GitOps different from CI/CD?

CI/CD automates build, test, and delivery. GitOps governs what is running, using Git as the desired state and a reconciler to enforce it. The two complement each other: CI builds and tests the artifact, and GitOps deploys and keeps it consistent. See What Is CI/CD?.

Do I need Kubernetes to use GitOps?

GitOps is most mature with Kubernetes, but the core idea — Git as the source of truth with an agent reconciling drift — applies to any system with a declarative configuration, including Terraform-managed clouds.

What is the difference between Argo CD and Flux?

Both are Kubernetes-native GitOps tools. Argo CD has a web UI and a strong model of application sync status; Flux is modular and more CLI-oriented. For a first project, Argo CD is often easier to visualize. See How to Set Up GitOps With Argo CD.