What is GitOps? Explained Simply for Beginners (2026)

You keep hearing "GitOps" but every explanation sounds like it was written for someone who already knows what it is. Let's fix that.

Start With a Problem

Imagine you have a Kubernetes cluster running your app. You need to deploy a new version. Traditionally, this is how it works:

1. Developer pushes code
2. CI pipeline builds a Docker image
3. Pipeline runs kubectl apply or helm upgrade to deploy
4. The cluster now has the new version... probably

The problem: the cluster is now the source of truth. If someone runs kubectl edit deployment myapp in production to make a quick fix, nobody knows about it. The config in Git doesn't match what's running. If you recreate the cluster, you don't know what to restore. The deployment script ran from your CI server at a specific moment — good luck reproducing it exactly.

This is the mess GitOps solves.

What is GitOps?

GitOps is a deployment approach where Git is the single source of truth for your infrastructure and applications.

Instead of running kubectl apply from a pipeline, you:

1. Declare what your cluster should look like in a Git repo
2. A tool running inside the cluster watches that repo
3. When the Git repo changes, the tool automatically syncs the cluster to match

Developer → Git repo (desired state)
                 ↑ source of truth
                 ↓ continuously synced
         Kubernetes Cluster (actual state)

The cluster never drifts from Git. If someone makes a manual change to the cluster, the GitOps tool detects the drift and reverts it.

The Core Principles of GitOps

1. Declarative configuration

Everything is described as "what I want," not "how to get there."

# This declares desired state
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.0.0

You're not saying "scale to 3 replicas" — you're saying "3 replicas should exist." The system figures out how to get there.

2. Versioned and immutable

All configuration lives in Git. Every change has a commit, author, timestamp, and message. You can see exactly what changed, when, and who approved it.

3. Pulled automatically

The cluster pulls changes from Git — it's not pushed to by an external system. This is a big security advantage: the cluster doesn't need inbound access or credentials stored in CI systems.

4. Continuously reconciled

The GitOps agent constantly compares desired state (Git) with actual state (cluster) and fixes any drift. The cluster is always trying to match what Git says.

GitOps vs Traditional CI/CD

Here's the key difference visually:

Traditional CI/CD (Push-based):

Code push
  → CI pipeline builds image
  → Pipeline authenticates to cluster
  → Pipeline runs kubectl apply / helm upgrade
  → Done (until someone manually changes something)

GitOps (Pull-based):

Code push
  → CI pipeline builds image
  → CI pipeline updates image tag in Git (manifests repo)
  → GitOps agent (running in cluster) detects Git change
  → Agent pulls and applies the new state
  → Cluster continuously stays in sync with Git

The cluster never has to give your CI system access to run commands. The cluster does the pulling itself.

The Main GitOps Tools

ArgoCD

The most popular GitOps tool in 2026. ArgoCD runs inside your Kubernetes cluster and has a web UI where you can see every application's sync status.

# Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

You define an Application that points to a Git repo:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/myapp-manifests
    targetRevision: main
    path: k8s/
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true      # Delete resources removed from Git
      selfHeal: true   # Revert manual changes

ArgoCD watches the Git repo. Any change to k8s/ gets automatically applied to the cluster.

Flux

The other major GitOps tool. More Kubernetes-native, CNCF graduated, preferred by teams that want everything in YAML without a UI.

# Flux GitRepository source
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/myorg/myapp-manifests
  ref:
    branch: main
---
# Flux Kustomization (applies the manifests)
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 5m
  path: ./k8s
  prune: true
  sourceRef:
    kind: GitRepository
    name: myapp

A Real GitOps Workflow

Here's how a code change flows in a GitOps setup:

1. Developer writes code, opens PR

git checkout -b feature/add-new-endpoint
# Write code
git push origin feature/add-new-endpoint
# Open PR → gets reviewed → merged to main

2. CI pipeline builds and tags the image

# GitHub Actions
- name: Build and push image
  run: |
    docker build -t myapp:${{ github.sha }} .
    docker push myapp:${{ github.sha }}

3. CI updates the image tag in the manifests repo

- name: Update image tag in manifests
  run: |
    sed -i "s|image: myapp:.*|image: myapp:${{ github.sha }}|" k8s/deployment.yaml
    git commit -am "chore: update myapp to ${{ github.sha }}"
    git push

4. ArgoCD detects the change and syncs

ArgoCD sees the new commit in the manifests repo. It compares the new deployment.yaml to what's in the cluster. Image tag changed → rolls out new pods automatically.

5. To roll back, just revert the Git commit

git revert HEAD
git push
# ArgoCD applies the revert → pods roll back to previous image

No helm rollback, no special commands. Git history is your audit trail and your rollback mechanism.

Why Companies are Adopting GitOps

Audit trail: "Who deployed what, when?" is now just git log.

Security: No credentials needed in CI pipelines to reach the cluster.

Disaster recovery: If your cluster disappears, pointing ArgoCD at your Git repo recreates everything.

Multi-cluster management: Manage 20 clusters from one Git repo. ArgoCD's ApplicationSet can deploy the same app across all clusters automatically.

Compliance: Every change to production was reviewed in a PR. That's your change management process, built in.

Getting Started

The fastest way to try GitOps:

1. Install Minikube or use a cloud cluster
2. Install ArgoCD (5 minutes)
3. Push some Kubernetes manifests to a GitHub repo
4. Create an ArgoCD Application pointing to that repo
5. Change the image tag in your repo — watch ArgoCD sync it automatically

The click-by-click tutorial is all in the ArgoCD Getting Started docs.

Resources

• ArgoCD Documentation — best place to learn ArgoCD deeply
• KodeKloud GitOps with ArgoCD Course — hands-on labs, fastest way to go from theory to practice
• DigitalOcean $200 free credit — spin up a real Kubernetes cluster to practice GitOps
• CNCF GitOps Working Group — the original GitOps principles document

GitOps is one of those ideas that seems complicated until you actually try it — then it seems obvious. Git is already where your code lives. Why not make it where your cluster's desired state lives too?

Once you've run git revert to roll back a production incident in 30 seconds, you'll never want to go back.