Skip to main content
Let’s review core GitOps terminology and how the pieces fit together. GitOps uses Git as the single source of truth for declarative configuration, combined with automated reconciliation, to manage infrastructure and applications. Below we explain the key concepts you see on the screen and show practical examples.
A diagram titled "GitOps" showing colored labels for concepts like Continuous, Declarative, Desired State, State Drift, State Reconciliation, State Store, Feedback Loop, Rollback, and GitOps Managed System. A caption explains managing infrastructure and applications using Git as the single source of truth for declarative configuration with automated reconciliation.

​
1. Continuous (Reconciliation)

In GitOps the reconciliation process is continuous — it runs constantly rather than executing once. Continuous reconciliation ensures the running system continuously converges toward the desired state declared in Git. This always-on loop detects deviations (e.g., a pod crash or a manual change) and automatically attempts to correct them. Think of it like a thermostat: it continuously checks the temperature and adjusts heating or cooling to maintain the setpoint.
A slide showing a continuous deployment loop: a bot continuously compares a GitHub repo and syncs desired manifests to a Kubernetes cluster. To the right is a thermostat-style control showing 78° with a hand pressing a green button.
Continuous reconciliation reduces manual toil and improves reliability by keeping the actual system in sync with the state declared in Git.

​
2. Declarative

Declarative configuration describes the end state you want, not the exact sequence of commands to reach it. In imperative workflows you run kubectl commands directly; in declarative workflows you store YAML manifests in Git and let the GitOps operator apply them. Imperative example (creating resources via kubectl): 
kubectl create deployment nginx-deployment \
  --image=nginx:latest \
  --replicas=5 \
  --port=80

kubectl expose deployment nginx-deployment \
  --type=LoadBalancer \
  --port=80 \
  --target-port=80 \
  --name=nginx-service
Declarative example (store these manifests in Git under .k8s/manifests): 
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-deployment
  name: nginx-service
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-deployment
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment
  name: nginx-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      labels:
        app: nginx-deployment
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        ports:
        - containerPort: 80
Why declarative matters:
  • Easier to understand the system intent.
  • The operator chooses how to apply changes and adapt to the environment.
  • Git provides versioning and an audit trail for every change.

​
3. Desired State

Desired state is the canonical configuration stored in your state store (typically Git). It is the plan GitOps aims to realize in the running system. Example repository layout:
  • .k8s/manifests/service.yaml
  • .k8s/manifests/deployment.yaml
  • .k8s/manifests/configmap.yaml
  • .k8s/manifests/ingress.yaml
Each file (Deployment, Service, ConfigMap, Ingress) together represents the desired state for that application or cluster. A well-defined desired state lets you measure success, reproduce environments, and collaborate through Git workflows.

​
4. State Drift

State drift occurs when the actual system state diverges from the desired state declared in Git. Drift can be caused by manual kubectl edits, failed deployments, or unauthorized changes. Why state drift is a problem:
  • Causes unexpected behavior and instability.
  • Makes troubleshooting harder if there’s no single source of truth.
  • Can introduce untracked or insecure configurations.
Example scenario:
  • Desired state (Git): deployment with 5 replicas.
  • Actual state (cluster): someone ran kubectl scale to reduce replicas to 3 — this is drift.

​
5. State Reconciliation

State reconciliation is the automated process of detecting drift and bringing the actual state back into alignment with the desired state. GitOps operators (observe → diff → act) implement reconciliation continuously. Reconcile loop diagram:
A "State Reconciliation" diagram showing a circular reconcile loop with arrows labeled Observe, Diff, and Act around a central "Reconcile Loop." To the right are two colored boxes labeled Desired State (Git) and Actual State (Kubernetes Cluster).
Reconciliation example (drift correction): 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment
  name: nginx-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      labels:
        app: nginx-deployment
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        ports:
        - containerPort: 80
If someone manually scales the deployment: 
kubectl scale deploy nginx-app --replicas=3
A GitOps operator like FluxCD or ArgoCD will detect the diff and reconcile the cluster back to 5 replicas automatically. Why reconciliation matters:
  • Provides self-healing and resilience.
  • Guarantees consistency with declared configuration.
  • Reduces manual intervention and operational risk.

​
6. GitOps Managed Systems

A GitOps-managed system is any application or infrastructure component controlled via GitOps — most commonly Kubernetes clusters, but also cloud resources via tools like Terraform stored in Git. Everything needed to run and manage the system lives in the Git repository: namespaces, RBAC, deployments, services, monitoring stacks, etc.
Diagram of a GitOps-managed software system. It shows Kubernetes manifests, Helm charts and Terraform/Ansible files in a Git repo feeding a GitOps operator that deploys to Kubernetes and cloud providers (Azure, Google Cloud, AWS).

​
7. State Store

The state store is the centralized repository holding the desired state. Git is the most common state store because it provides:
  • A single source of truth
  • Immutable history and audit trails
  • Branching, pull requests, and code review workflows for collaboration
Other systems can be used, but Git’s workflows and tooling make it ideal for teams.

​
8. Feedback Loop

A feedback loop closes the cycle between deployment and operation: metrics, logs, and alerts inform adjustments to the desired state and reconciliation behavior. Monitoring and alerting tools detect problems in the running system and feed that information back to teams to trigger fixes or rollbacks. Example workflow:
  • GitOps operator deploys a new version.
  • Prometheus detects increased error rates.
  • Grafana dashboards visualize the issue; Alertmanager notifies the on-call team.
  • Team reverts or patches the manifest in Git → reconciliation applies the fix.
Useful links: Why feedback loops matter:
  • Detect issues early in production.
  • Improve desired-state definitions based on real-world behavior.
  • Allow iterative improvements driven by telemetry.

​
9. Rollback

Rollbacks are fast recovery mechanisms to revert problematic changes. In GitOps, rollbacks are typically done by reverting commits in Git or by letting GitOps tools perform automatic rollbacks when they detect failures. Methods:
  • Git revert: create a new commit that undoes a previous change (preserves history).
# Example git revert command
git revert o3u9n
[master s5e79] Revert "Config change"
 1 file changed, 1 deletion(-)
  • Operator-driven rollback: ArgoCD and similar tools can be configured to revert to a known-good state automatically if health checks fail.
Why rollback matters:
  • Speeds recovery after bad deployments.
  • Minimizes downtime and risk.
  • Gives teams confidence to ship changes more frequently.

​
Quick Reference Table

ConceptWhat it meansExample / Tooling
ContinuousAlways-on reconciliation loopArgoCD, FluxCD
DeclarativeDescribe desired state, not stepsKubernetes YAML manifests
Desired StateCanonical config stored in Git.k8s/manifests/*
State DriftActual ≠ Desired (unauthorized changes)kubectl scale changed replicas
ReconciliationDetect and correct drift (observe → diff → act)GitOps operator
State StoreCentral repo (single source of truth)Git
Feedback LoopTelemetry → alerts → changes in GitPrometheus, Grafana, Alertmanager
RollbackRevert changes quickly via Git or operatorgit revert, ArgoCD auto-rollback

​
Tools & Further Reading

While GitOps automates reconciliation, ensure you have proper observability and guardrails (health checks, alerts, RBAC) in place—automation without visibility can amplify issues.

Watch Video