GitOps Explained: Git as the Single Source of Truth for Infrastructure (2026)

GitOps flips the script on managing infrastructure by treating your Git repository as the only place where the desired state of your systems is declared.

Let’s see it in action with a Kubernetes example. Imagine you have a deployment for your web application. In Git, this would be a YAML file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.0
        ports:
        - containerPort: 80

This file lives in a Git repository. A dedicated GitOps agent, often running inside your Kubernetes cluster (like Argo CD or Flux CD), continuously monitors this repository. When it detects a change – say, you update the image to nginx:1.21.1 or increase replicas to 4 – it automatically synchronizes the cluster’s state to match this declared state in Git.

The core problem GitOps solves is the disconnect between what you think your infrastructure looks like and what it actually looks like. Manually updating infrastructure, often through imperative commands (kubectl apply -f ...), leads to drift. GitOps eliminates this drift by making Git the undeniable source of truth. Any change to infrastructure must go through a Git commit and pull request. This brings all the benefits of Git – history, collaboration, auditability, and rollback capabilities – to your infrastructure management.

Internally, a GitOps agent watches a specific Git repository and branch. It compares the resources defined in Git (the "desired state") with the resources running in the cluster (the "actual state"). If there’s a discrepancy, it initiates an action to reconcile the actual state with the desired state. This reconciliation can involve applying new Kubernetes manifests, updating existing ones, or even deleting resources. The agent itself is typically deployed as a Kubernetes Deployment and often runs with elevated privileges to manage other cluster resources.

The key levers you control are:

• The Git Repository: This is your central hub. You define your entire infrastructure as code here – Kubernetes manifests, Terraform configurations, Helm charts, etc.
• The Git Branch Strategy: Typically, a main or master branch represents the production environment, while feature branches are used for development and testing. Pull requests are the gatekeepers for merging changes.
• The GitOps Agent: This is the automated operator within your cluster. You configure which repositories and branches it should monitor and how it should reconcile differences. For example, with Argo CD, you’d define an Application resource pointing to your Git repo and the path containing your manifests.

A common misconception is that GitOps is only for Kubernetes. While it’s a perfect fit due to Kubernetes’ declarative nature, the principles apply to any infrastructure that can be described declaratively. Tools like Terraform can be managed with GitOps, where the GitOps agent applies Terraform plans based on Git commits, ensuring your cloud infrastructure (AWS, GCP, Azure) also adheres to the state defined in Git.

The next step in understanding GitOps is exploring how to manage sensitive configuration data, like database passwords or API keys, securely within a GitOps workflow.