What Is GitOps? Git-Driven Infrastructure Deployment Explained

GitOps is an operating model where a Git repository is the single source of truth for a system’s desired infrastructure and application state, and an automated agent continuously reconciles the live environment to match whatever is committed. Instead of an engineer running deployment commands against a cluster, they open a pull request; once it merges, a controller inside the cluster notices the change and applies it — Git becomes the interface to production, not just a place source code happens to live.

The core idea: desired state in Git, reconciliation in the cluster

Every GitOps setup has two parts:

1. A Git repository holding declarative configuration — Kubernetes manifests, Helm values, Terraform files, or similar — describing what the system should look like: which container images are running, how many replicas, what config values are set.
2. An operator or controller running inside the target environment that watches the repository, compares its contents to the actual live state, and applies whatever changes are needed to bring the two into agreement. Tools like Argo CD and Flux are the common implementations of this role for Kubernetes.

The controller runs a continuous loop: pull the latest committed state, diff it against reality, apply the difference, repeat. If someone manually changes something in the live cluster — a kubectl edit in a moment of urgency — the next reconciliation pass reverts it back to whatever Git says, because Git, not the cluster’s current state, is the authority.

How this differs from a traditional CI/CD pipeline

A conventional deployment pipeline is push-based: a CI job builds an artifact, and at the end of the pipeline it authenticates to the target environment and pushes the change — kubectl apply, a cloud CLI command, an SSH script. The pipeline needs credentials that can write to production, and the deployment happens as a one-shot action triggered by the pipeline finishing.

GitOps flips this to pull-based: the controller living inside the target environment is the one with write access to that environment, and it pulls from Git rather than being pushed to. The CI/CD pipeline’s job shrinks to building an artifact and updating a manifest in the Git repo — it never needs credentials for the production cluster at all. This is a meaningful security improvement: the biggest attack surface in a push model, a CI system holding deploy credentials to production, doesn’t exist in the same form in a pull model.

It also means the controller keeps enforcing the desired state continuously, not just at deploy time — configuration drift, whether from a manual hotfix or an unrelated process changing something, gets corrected automatically on the next reconciliation, rather than persisting until the next scheduled deployment. This overlaps conceptually with blue-green and canary deployment strategies, which also aim to make rollout state explicit and controllable — GitOps just adds Git as the record of what that state should be at every point in time.

Rollbacks become git reverts

Because the desired state lives entirely in version-controlled files, rolling back a bad deployment is the same operation as reverting a bad code change: revert the commit, and the reconciliation loop pulls the reverted state and applies it. There’s no separate “rollback procedure” distinct from the normal Git workflow, and the repository’s commit history doubles as an audit log of every infrastructure change, who approved it, and when — useful for observability and compliance alike, since “what changed and why” is answered by git log instead of a separate change-management system.

Push-based CI/CD vs GitOps

	Push-based CI/CD	GitOps
Who applies changes	The pipeline, at deploy time	A controller inside the target environment, continuously
Production credentials	Held by the CI system	Held by the in-cluster controller only
Drift correction	None until the next deploy	Automatic, on every reconciliation pass
Rollback	A separate rollback step or script	git revert
Audit trail	Pipeline logs	Git commit history
Best fit	Simpler deployments, non-Kubernetes targets	Kubernetes and other declarative infrastructure

Where it fits and where it doesn’t

GitOps works best where the target system is genuinely declarative — Kubernetes is the dominant case, since a manifest fully describes desired state and the API server already reconciles toward it. It fits less naturally onto imperative, one-off operations (running a database migration, rotating a secret that isn’t itself stored in Git) that don’t reduce cleanly to “make the live state match this file.” Most real GitOps setups combine declarative reconciliation for infrastructure and deployments with a conventional pipeline for the imperative steps that don’t fit the model, rather than trying to force everything through Git.

It also depends on solid CI discipline upstream: GitOps controls what gets applied to production, not how the artifact was built or tested in the first place — a bad image that passes review and gets merged will be reconciled into production just as faithfully as a good one.

The takeaway

GitOps makes a Git repository the authoritative record of what infrastructure and deployments should look like, with an automated controller continuously pulling that state into the live environment rather than a pipeline pushing changes into it. That flip — pull instead of push — removes the need for CI systems to hold production credentials, turns rollbacks into ordinary Git reverts, and gives every infrastructure change a commit-history audit trail. It’s the strongest fit for genuinely declarative systems like Kubernetes, and works best paired with, not instead of, solid CI practices upstream.