What Is GitOps? The Beginner's Guide (The Four Principles, Pull vs Push, GitOps vs DevOps, and the Tool Lane)
CodexFuse Team · 2026-11-03T15:00:47.854Z · 17 min read min read
What Is GitOps? The Beginner's Guide (The Four Principles, Pull vs Push, GitOps vs DevOps, and the Tool Lane)
What is GitOps? It is the practice of making a Git repository the single source of truth for your infrastructure and deployments — so every change to production starts as a pull request, and an automated agent continuously keeps your live systems matching what Git says they should be. GitOps extends DevOps: instead of pushing deployments from CI pipelines, software agents pull the desired state from Git and reconcile it automatically, which gives infrastructure changes the same review, rollback, and audit discipline as application code. This beginner's guide covers the four OpenGitOps principles, the pull-vs-push models, GitOps vs DevOps vs CI/CD, the drift and rollback mental model, and the Argo CD/Flux/Kargo tool lane. If Git itself is new to you, start with our Git beginner guide; the concepts here build directly on it. And if you want the flagship tool that implements GitOps, our Argo CD beginner guide picks up where this explainer leaves off.
What Is GitOps, Exactly?
GitOps is an operational model where a Git repository holds the declarative desired state of your infrastructure and applications, and software agents running inside the target environment automatically pull that state and apply it. The one-sentence version to memorize: if it is not in Git, it does not exist in your infrastructure. Every change — application code, server configuration, environment variables, deployment settings — starts as a commit, gets reviewed as a pull request, and lands in production only through the agent. People change production by merging a pull request, not by running commands on servers.
The term blends "Git" and "operations," and the name tells you the whole idea: take the workflows developers already trust (branches, pull requests, merges, rollbacks, code review) and apply them to operations work. A GitOps setup has three moving parts: a Git repository containing declarative configuration files (usually YAML manifests) that describe what should run; an agent (such as Argo CD or Flux) that watches the repository and the live environment; and a reconciliation loop that detects drift — any difference between the desired state in Git and the actual state — and fixes it automatically.
The practical payoff is easiest to state with rollback: with GitOps you roll a cluster back with git revert, and every approved change is explainable through the commit log. Routing normal changes through Git while an in-cluster agent detects drift gives infrastructure changes the same review and rollback discipline as application code — and Git preserves their history.
Where Did GitOps Come From?
The term "GitOps" was coined by Alexis Richardson, the CEO of Weaveworks, in an August 2017 blog post titled "Operations by Pull Request." The origin story is a real disaster: during a Weaveworks system failure in 2016 that took down everything the company hosted, the team recovered in under an hour because every configuration, setting, and piece of infrastructure was described in code and versioned in Git — they simply restored from their single source of truth. The incident became the pattern: Git as the control plane for operations.
Weaveworks did not survive to steward the idea forever. In February 2024, Richardson announced that Weaveworks would close its doors and shut down commercial operations (reported by TechCrunch on February 5, 2024), after a last-minute M&A deal fell through. But the concept outlived the company: stewardship of the definition passed to the CNCF's OpenGitOps working group — a CNCF Sandbox project launched by Amazon, Azure, Codefresh, GitHub, Red Hat, and Weaveworks with more than 60 companies participating. Say the history once: Weaveworks invented it, CNCF maintains it now. And note that Flux CD, originally Weaveworks' own project, continues as an independent CNCF project — Flux 2.2 went generally available in December 2023, just before the company's closure.
The Four GitOps Principles
The OpenGitOps working group published the canonical definition as OpenGitOps Documents v1.0.0 on November 8, 2021. These four principles are the official test of whether a workflow is GitOps — quote them, don't water them down:
| Principle | Canonical definition | What it means in practice |
|---|---|---|
| 1. Declarative | "A system managed by GitOps must have its desired state expressed declaratively." | You write files that describe what the system should look like, not scripts that perform steps. A YAML manifest saying "three replicas of orders-api v1.5.0" instead of a bash script that installs and configures them. |
| 2. Versioned and Immutable | "Desired state is stored in a way that enforces immutability, versioning and retains a complete version history." | The desired state lives in Git. Every version has an author, a timestamp, a commit message, and a diff — and a commit never changes after it is made. Rollback is just moving back to an earlier commit. |
| 3. Pulled Automatically | "Software agents automatically pull the desired state declarations from the source." | The agent inside the system fetches changes from Git itself. Nobody runs a deploy command, and the cluster never needs inbound credentials handed out to a CI system. |
| 4. Continuously Reconciled | "Software agents continuously observe actual system state and attempt to apply the desired state." | The agent keeps comparing Git's desired state with the live state and corrects any drift — the self-healing loop that separates GitOps from regular CI/CD. |
Notice the two halves: the first two principles cover how you describe and store the desired state (declarative files, in Git, immutable); the last two cover how that state reaches and stays in the system (agents pull it, and continuously reconcile it). This structure matters, because it tells you exactly which half a tool covers — Argo CD and Flux are the agents of the second half.
How the GitOps Loop Works
The GitOps loop is a six-step cycle, and every change to your system follows the same path:
- A developer changes a file and opens a pull request. It can be application code, a server configuration file, an environment variable, or a deployment setting — it all starts as a Git change.
- The pull request is reviewed and merged. Code review is the approval mechanism, so operations changes get the same scrutiny as application changes. This is the "operations by pull request" part.
- The agent notices the new desired state. The in-cluster agent watches the repository — by polling it on an interval or by receiving a webhook — and picks up the merged commit.
- The agent compares desired state with live state. If Git says three replicas and the cluster is running three replicas, nothing happens. If someone hand-edited something (drift), the agent flags it as out of sync.
- The agent applies the desired state. It makes the live system match Git — starting containers, updating configurations, deleting resources that Git no longer declares.
- The agent keeps watching. Steps 3–5 repeat continuously, so any future drift is detected and corrected. The loop never stops.
That last step is what separates GitOps from regular CI/CD. A CI/CD pipeline runs once when you push code; a GitOps agent runs forever, watching for drift. Merge the pull request and your job is done — the agent does the deploying, on its own schedule, forever.
Pull vs Push: The Two GitOps Models
The third principle says agents should pull the desired state, and pull is the canonical GitOps model: an agent lives inside the cluster and is responsible for changing the current state to the desired state of the system. But push-based deployments are also common in practice. The honest comparison:
| Pull model (canonical GitOps) | Push model (common in practice) | |
|---|---|---|
| How deploys happen | An in-cluster agent fetches the desired state from Git and applies it itself | An external CI pipeline pushes changes to the cluster after a commit, usually via webhook |
| Cluster credentials | The cluster needs no inbound credentials handed to outside systems — the agent pulls, nothing pushes in | The CI system must hold cluster credentials, which widens credential exposure |
| Drift detection | Continuous: the agent always compares Git against the live cluster and corrects drift | Typically none: the pipeline runs once per commit and does not watch for hand-edits |
| Works with | Best with orchestrators like Kubernetes that an agent can reconcile against | Any infrastructure — VMs, servers, managed services |
| Simplicity | More moving parts (you run and maintain the agent) | Simpler, and it is what most teams already have in place |
The reality most teams live in: most teams use push-based GitOps, and that is fine — the purist principle says pull, but a Git-driven workflow with review, versioning, and rollback is already GitOps in spirit. The GitOps pull vs push decision comes down to infrastructure: use pull when you want self-healing clusters and no inbound credentials; use push when your infrastructure is VMs and servers that no agent can reconcile. Draw the line once, then follow the workflow you can actually maintain.
GitOps vs DevOps vs CI/CD
The standard framing is: GitOps is a way to do DevOps, with a focus on declarative configuration and Git-based workflows for continuous delivery. It is not "GitOps versus DevOps" — it is GitOps with DevOps. DevOps is the broad culture and practice; CI/CD is the pipeline practice inside it; GitOps is the Git-as-source-of-truth operational model that extends DevOps into deployments.
| DevOps | CI/CD | GitOps | |
|---|---|---|---|
| Scope | Culture, collaboration, and automation across dev and ops | Automated build, test, and delivery pipelines | An operational model where Git is the single source of truth for desired state |
| How changes reach production | Through shared practices and pipelines | CI pushes changes through a pipeline to the cluster | An in-cluster agent pulls changes from Git |
| Approval mechanism | Team process | Pipeline gates and approvals | Pull request review |
| Rollback | Varies by implementation | Re-run an old pipeline and hope nothing else changed | git revert — the repo history is the rollback |
| Where it shines | Breaking down dev/ops silos | Building and testing code fast | Deploying infrastructure and apps safely, with full audit |
The cleanest one-liner from the field: CI still builds and tests, but with GitOps, CD is Git-driven. Your CI pipeline keeps doing what it does well — building images, running tests — and the GitOps agent takes over the deployment side.
GitOps Without Kubernetes?
GitOps was born in Kubernetes, and the canonical pull model assumes an agent that can reconcile against an orchestrator. But you do not strictly need Kubernetes. The push side of GitOps works anywhere: if your Git repository holds the declarative state of your servers or VMs and a pipeline applies it on merge, you get versioned, reviewed, rollback-able operations on plain servers too.
What you lose without Kubernetes is the continuous self-healing loop — a VM fleet has no single API surface for an agent to reconcile against, so drift detection becomes a scheduled script rather than a live watcher. The DeployHQ 2026 guide puts the rule well: an automated process detects the new commit, whether that is a CI/CD pipeline triggered by a webhook or a GitOps operator polling the repository. If you run containers on a VPS rather than a cluster, our Docker beginner guide is the right runtime foundation — and a Git repository describing your docker compose stack is a legitimate baby step into GitOps thinking.
The GitOps Tools Lane: Argo CD vs Flux vs Kargo
The GitOps tools beginners encounter first are not rivals — they occupy different slots in the GitOps workflow. One table, no deep dives; the tool topics carry the full how-tos.
| Tool | Slot in GitOps | Style | Version check (November 2026) |
|---|---|---|---|
| Argo CD | The in-cluster pull agent: watches Git, compares against the live cluster, syncs | Dashboard-first, cautious by default — shows an app as OutOfSync and only syncs when you enable it | v3.5.7 is the latest on the live releases page (github.com/argoproj/argo-cd, checked November 3, 2026). Self-heal and prune are both opt-in; allowEmpty defaults to false. |
| Flux | The in-cluster pull agent: source controller pulls Git, kustomize/Helm controllers build and apply | CLI-first, strict by default — corrects drift on every reconciliation interval | v2.10.0 is the latest on the live releases page (github.com/fluxcd/flux2, checked November 3, 2026). Defaults: GitRepository sources every 1 minute, Kustomizations every 10 minutes. |
| Kargo | Continuous promotion: moves changes from one environment stage to the next | Stages, Warehouses, and Freight CRDs; unopinionated, GitOps-principled | Latest release on docs.kargo.io; check at write time — version numbers move. |
The key relationship to memorize: Kargo sits between CI and the GitOps agent. GitOps provides no specific guidance on how changes propagate from the desired state of one stage (dev) to the next (staging, production) — that is exactly the process Kargo manages. But the job of deploying — making the actual cluster reflect the desired state — is left to a GitOps agent like Argo CD. Pipeline: CI builds and tests → Kargo promotes through stages → Argo CD or Flux deploys.
Argo CD's caution is a design choice worth understanding: by default, changes made to the live cluster do not trigger automated sync — Argo CD detects them but waits, and you enable self-healing explicitly with spec.syncPolicy.automated.selfHeal: true. Flux takes the opposite stance: hand-edit something with kubectl edit and the next reconciliation reverts it. Neither is "correct" — cautious versus strict is a team choice, and beginners should know which one they picked. Here is what a minimal Argo CD Application manifest looks like — this is the actual YAML that tells the agent what to watch:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: orders-api
spec:
project: default
source:
repoURL: https://github.com/your-org/orders-gitops.git
path: apps/orders-api/prod
destination:
server: https://kubernetes.default.svc
namespace: orders
syncPolicy:
automated:
prune: false # safety first: never auto-delete undeclared resources
selfHeal: false # report drift as OutOfSync; don't auto-revert
Read it as the contract between Git and the agent: the source says which repository path is the desired state, the destination says which cluster and namespace should match it, and the syncPolicy declares how cautious the agent must be. Every GitOps tool has an equivalent of this contract — different syntax, same three promises.
Drift, Rollback, and the Friday-Deploy Test
The fastest way to feel GitOps is to run the mental experiment every on-call engineer knows: the Friday 4 PM deploy. Here is the same incident, two ways.
The old way. Someone pushes a config change to production by hand at 4 PM. At 4:40 the service is down. At 4:50 the team is in the runbook: who changed what, on which server, in what order? The change exists only in someone's terminal history. Rolling back means reconstructing the old state from memory, re-running the steps in reverse, and hoping nothing else changed since.
The GitOps way. The same change went in as a pull request, got reviewed, merged, and applied by the agent. At 4:40 the service is down — but the team opens the Git log: one commit, one author, one diff, one timestamp. The rollback is git revert <commit>, push, and the agent syncs the old desired state back. Nobody reconstructs anything; Git is the history, and the agent is the deployer.
This is also the drift story. Drift is any difference between desired state and live state — ten replicas running when Git says three, a hand-edited environment variable, a config someone tweaked "just for now." In a traditional setup, drift accumulates silently until it bites. In GitOps, the agent finds it on its own loop and either reports it (Argo CD's OutOfSync) or fixes it (Flux's reverts). The Friday-deploy test is the litmus test for the whole idea: GitOps does not promise deploys never fail — it promises you always know what changed, who approved it, and how to undo it.
5 GitOps Mistakes Beginners Make
| Mistake | Why it hurts | The GitOps-correct habit |
|---|---|---|
| Hand-editing production and calling it a fix | The fix exists only in the live cluster — the next reconciliation or redeploy wipes it out, and nobody can review what you did | Make the fix as a commit. Even in an outage, the pull request is the change record; git revert is your rollback. |
| Storing secrets as plain YAML in the repo | Git history is forever — a secret committed in plaintext is leaked even after you delete the file | Use sealed/encrypted secrets (Sealed Secrets, SOPS, external secret stores). Git stores the sealed form; the agent decrypts in-cluster. |
| One giant repo for every environment and app | Merge conflicts on every change, one team's rollback reverts everyone's work, blast radius of a bad merge is everything | Separate repos (or at least folders/branches) per environment and application. Monorepos work, but environment separation is the default beginners should start from. |
| Turning on self-heal/prune before understanding it | Argo CD with prune enabled deletes resources not declared in Git — a misconfigured sync window can delete production workloads you expected to survive | Start cautious: drift reporting first, auto-sync second, prune last — and only with reviewed, tested manifests. |
| Skipping CI and expecting GitOps to build things | GitOps agents apply desired state; they do not build images or run tests. Pointing an agent at an untested image tag is just automated chaos | Keep CI for build and test. GitOps handles the CD side: the agent deploys only what CI already built, tested, and tagged. |
Sources
All facts in this guide were verified against these sources, fetched on November 3, 2026:
- OpenGitOps — OpenGitOps Documents v1.0.0 announcement (opengitops.dev, published November 8, 2021 — the four principles, quoted verbatim, and the CNCF Sandbox standing)
- OpenGitOps Documents — v1.0.0 release and repository README (github.com/open-gitops/documents — version confirmation and working-group citation block)
- GiantSwarm — What is GitOps (giantswarm.io — coining by Alexis Richardson, Weaveworks, 2017)
- TechCrunch — Weaveworks shuts its doors (techcrunch.com, published February 5, 2024 — closure announcement)
- The Register — Weaveworks pulls down cloud-native shutters (theregister.com, February 6, 2024 — Flux's CNCF continuation)
- Coralogix — What Is GitOps? Principles, Benefits, and How It Works (coralogix.com, updated October 2026 — rollback-by-revert framing, working-group/App Delivery SIG context)
- Argo CD documentation — Automated sync (argo-cd.readthedocs.io — OutOfSync behavior, self-heal and prune opt-in defaults)
- Argo CD — releases page (github.com/argoproj/argo-cd — v3.5.7 latest, checked November 3, 2026)
- Flux — releases page (github.com/fluxcd/flux2 — v2.10.0 latest, checked November 3, 2026; reconciliation interval defaults from Flux component docs)
- DeployHQ — What Is GitOps? CNCF Definition, Principles, and How It Works Without Kubernetes (deployhq.com, updated September 2026 — pull vs push trade-offs, four principles)
- Kargo documentation — FAQs and Core concepts (docs.kargo.io — continuous promotion definition, Argo CD as the deployment agent)
- Akuity — What is Kargo (akuity.io — progressive-delivery framing)
- CNCF — 2025 Cloud Native Survey announcement (cncf.io, January 20, 2026 — 58% of "cloud native innovators" use GitOps extensively vs 23% of "adopters")
- SC World — CNCF survey reveals widespread Kubernetes adoption (scworld.com, April 8, 2025 — 77% GitOps adoption "to some degree" among 689 IT professionals)
- SevyDevy — GitOps Explained (2026): Pull Sync, Drift and Rollback (sevydevy.in, October 2026 — Argo CD vs Flux defaults, rollback-by-revert behavior)
Frequently Asked Questions
Is GitOps the same as DevOps?
No — GitOps is a way to do DevOps, not a replacement for it. DevOps is the broad culture and practice of dev-ops collaboration; GitOps is a specific operational model inside it, where Git is the single source of truth for desired state and agents pull and reconcile it. As the field puts it: use DevOps principles for CI (build, test, package) and GitOps for CD (continuous delivery into environments).
What is the difference between GitOps and CI/CD?
CI/CD pipelines push changes to the cluster when code is committed, and they stop watching once the pipeline finishes. GitOps flips the model: an in-cluster agent pulls the desired state from Git and continuously reconciles it, so drift is detected and corrected even when no pipeline is running. In practice, teams keep CI for build and test and hand the deployment side to the GitOps agent — CI builds and tests, CD is Git-driven.
Do I need Kubernetes to use GitOps?
Not strictly. The canonical pull model assumes an orchestrator an agent can reconcile against, but the push side of GitOps works anywhere — a Git repository holding your server or VM state, applied by a pipeline on merge, gives you versioned, reviewed, rollback-able operations on plain servers. What you lose without Kubernetes is the continuous self-healing loop; drift detection becomes a scheduled check rather than a live watcher.
Which GitOps tool should a beginner start with?
Start with Argo CD if you want a dashboard and cautious defaults (it reports drift as OutOfSync and only syncs when you enable it), or Flux if you prefer CLI-first automation with strict defaults (it reverts hand-edits on every reconciliation). Both implement the pull model; the choice is workflow, not religion. Add Kargo later, when you need to promote changes through dev, staging, and production with rules.
Can GitOps roll back a bad deploy?
Yes — rollback is GitOps' headline feature. Because every change is a commit, rolling back is git revert on the offending commit, push, and let the agent sync the old desired state back. One caveat beginners hit: in Argo CD, some operators disable auto-sync during incidents and do a manual rollback instead; the Git commit should still record the change, so the repo history stays the single source of truth.
