What Is GitOps? Git as the Source of Truth for Infrastructure

GitOps is an operating model for infrastructure and applications where the entire desired state of a system is stored declaratively in Git, and an automated agent running inside the target environment continuously reconciles the real state to match what's in Git. Instead of engineers pushing changes into a cluster by running commands, they commit changes to a repository, and software pulls those changes and applies them. Git becomes the single source of truth, every change is a version-controlled commit, and the live environment is expected to converge on whatever the repository declares.

That's the whole idea in one paragraph. The rest of this post explains how the reconcile loop actually works, the principles that make GitOps different from "we keep our YAML in Git," and the problems it solves that traditional deployment pipelines don't.

---

How GitOps works

At the center of GitOps is a reconcile loop. You declare the desired state of your system — Kubernetes manifests, Helm values, Kustomize overlays, infrastructure definitions — and store it in a Git repository. An agent watches both the repository and the running environment, computes the difference between them, and takes action to close the gap.

The loop runs continuously:

1. Observe — the agent reads the desired state from Git and the actual state from the live cluster.
2. Diff — it compares the two and identifies what has drifted.
3. Act — it applies whatever changes are needed to make actual state match desired state.
4. Repeat — it does this on a schedule (every few minutes) and often in response to Git webhooks.

The critical detail is that this is pull-based, not push-based. In a traditional pipeline, a CI server holds cloud credentials and pushes deployments into the cluster from the outside. In GitOps, an agent lives inside the cluster — Argo CD or Flux are the two dominant implementations — and pulls the desired state in. The cluster reaches out to Git; Git never reaches into the cluster. That inversion is what gives GitOps most of its security and reliability properties, which I'll get to below.

Because the agent is always reconciling, it doesn't just apply changes when you commit — it also corrects drift. If someone runs kubectl edit on a live Deployment, or a rogue script scales something down, the agent notices the divergence from Git on its next pass and puts the cluster back to the declared state. The repository wins, always.

---

Core principles

The GitOps community, led by the OpenGitOps working group, distills the model into four principles. They're worth stating precisely because "we store YAML in Git" satisfies none of them on its own.

• Declarative. The entire system is described by declarative configuration — what the end state should be, not the imperative steps to get there. You declare "three replicas of this image," not "run this command to scale up."
• Versioned and immutable. Desired state is stored in a way that enforces immutability and full version history. Git provides this natively: every state is a commit, nothing is silently mutated, and the complete history is auditable.
• Pulled automatically. Software agents automatically pull the desired state from the source. No human runs kubectl apply; the agent does, on its own schedule.
• Continuously reconciled. Agents continuously observe actual state and attempt to apply the desired state. Reconciliation is a loop, not a one-shot deploy — which is exactly what makes drift correction possible.

If any one of these is missing, you have "Git-backed config," not GitOps. Storing manifests in a repo but applying them by hand from a laptop fails the pulled and continuously reconciled tests, and you lose most of the benefits.

---

What problems it solves

GitOps isn't ceremony for its own sake. It targets specific, recurring failure modes in how teams operate infrastructure.

Configuration drift. Without continuous reconciliation, live environments slowly diverge from any recorded state through hotfixes, manual edits, and half-finished changes. GitOps makes drift visible and self-correcting: the agent flags anything that doesn't match Git and can revert it automatically.

No reliable audit trail. When changes are pushed via ad-hoc commands or a CI job with broad credentials, "who changed what, when, and why" is scattered across logs. In GitOps, every change is a commit with an author, a timestamp, and — if you gate main behind pull requests — a review and approval record. Your Git history is your change log.

Painful, risky rollbacks. Rolling back usually means re-running a pipeline with older parameters and hoping. In GitOps, the previous good state is just an earlier commit, so a rollback is a git revert. The agent sees the reverted desired state and reconciles the cluster back to it — same mechanism as any other change, no special path.

Credential sprawl. Push pipelines need cluster-admin credentials stored in the CI system, which becomes a high-value target reachable from the internet. With a pull agent, credentials stay inside the cluster and never leave it; your CI system doesn't need cluster access at all.

Environment reproducibility. Because the full desired state lives in Git, standing up an identical staging cluster — or rebuilding a lost one — is a matter of pointing an agent at the repository. The repo describes the whole environment, not just the diff you happened to deploy last.

---

GitOps vs traditional CI/CD push

The distinction people miss is that GitOps doesn't replace CI — it changes CD.

In a traditional push model, a CI/CD pipeline builds your artifact, runs tests, and then, in the same pipeline, uses stored credentials to push the deployment into the target cluster. The pipeline is the actor; the cluster is a passive recipient. State lives wherever the last successful pipeline run left it.

In GitOps, CI still builds and tests, but instead of deploying, it writes the new desired state (usually a bumped image tag) to a Git repository. From there an in-cluster agent pulls the change and reconciles. CI proposes; the agent disposes. See Argo CD in production for how this split looks in a real setup.

The practical differences: push pipelines are point-in-time (they deploy once and stop), while GitOps is continuous (it keeps enforcing state). Push needs outbound credentials into the cluster; GitOps keeps them inside. Push has no built-in drift detection; GitOps has it for free. GitOps is not "better CI" — it's a fundamentally different placement of the deployment authority.

---

Common misconceptions

"GitOps means storing YAML in Git." Storage is necessary but nowhere near sufficient. Without a reconciling agent pulling and enforcing that state, you have version control, not GitOps.

"GitOps replaces my CI pipeline." It doesn't. You still need CI to build images and run tests. GitOps replaces the delivery half — the part that used to push into the cluster.

"GitOps only works with Kubernetes." The best-known tools are Kubernetes-native, but the model — declarative state in Git, an agent reconciling actual to desired — applies to anything with a declarative API. Terraform-based and infrastructure control-plane workflows adopt the same pattern.

"GitOps is just Argo CD." Argo CD is one implementation. Flux is the other major one, and the two make different tradeoffs. If you're choosing, the Argo CD vs Flux comparison breaks down the differences.

"GitOps and Infrastructure as Code are the same thing." IaC is about describing infrastructure declaratively. GitOps is an operating model that uses declarative config plus continuous reconciliation and pull-based agents. IaC is an ingredient; GitOps is the recipe.

---

Frequently Asked Questions

Is GitOps only for Kubernetes?

No. The most mature tooling is Kubernetes-native because Kubernetes already exposes a declarative reconciliation API, which fits GitOps perfectly. But the model — declarative desired state in Git, reconciled continuously by a pulling agent — works for any system with a declarative interface, including cloud infrastructure managed through control planes and Terraform-style workflows.

Does GitOps replace CI/CD?

It replaces the CD half, not CI. Continuous integration still builds artifacts and runs tests. GitOps changes how the delivery happens: instead of a pipeline pushing into the cluster, CI writes the new desired state to Git and an in-cluster agent pulls and applies it.

How do rollbacks work in GitOps?

A rollback is a git revert (or a reset to a previous commit). Because every desired state is a commit, reverting to an earlier one restores the previous configuration. The agent detects the changed desired state on its next reconcile and converges the environment back — using the exact same mechanism as a forward deployment, with no special rollback path.

What is drift and how does GitOps handle it?

Drift is when the live environment no longer matches what's declared in Git — usually from manual edits or out-of-band scripts. Because a GitOps agent reconciles continuously, it detects drift on every pass and can automatically revert the environment to the declared state. Git always wins.

What's the difference between push and pull deployments?

In a push model, an external system (like a CI server) holds cluster credentials and pushes changes in. In a pull model, an agent inside the cluster pulls the desired state from Git and applies it. Pull keeps credentials inside the cluster, enables continuous reconciliation, and reduces the attack surface — which is why GitOps is pull-based by design.

---

See also

• The complete guide to Argo CD and GitOps on Kubernetes — the deepest walkthrough of the leading GitOps agent.
• GitOps with Argo CD in production — patterns, repo structure, and pitfalls for real deployments.
• Argo CD vs Flux CD compared — how the two dominant GitOps tools differ and how to choose.

Trying to decide whether GitOps is right for your team, or how to roll it out without breaking existing pipelines? Talk to us at Coding Protocols — we help platform teams adopt GitOps safely and get continuous, auditable delivery working in production.

Official References

• Argo CD declarative setup — the Application and AppProject spec
• Argo CD sync options — prune, self-heal and sync-wave behaviour
• Flux controllers — what each controller reconciles