Skip to main content
Explore essential GitOps terminology and how the concepts fit together. GitOps is the practice of managing infrastructure and applications using Git as the single source of truth for declarative configuration with automated reconciliation. This article clarifies key GitOps terms and shows how they relate: continuous reconciliation, declarative manifests, desired state, state drift, reconciliation, feedback loops, rollbacks, and the state store.
The image illustrates GitOps concepts with labeled elements like "Continuous," "Declarative," and "Desired State," alongside descriptions of managing infrastructure using Git for declarative configuration.

​
Continuous

In GitOps, reconciliation is continuous — an ongoing loop that ensures the running system matches the declared configuration. Continuous reconciliation reacts to changes (for example, pod crashes or ad-hoc manual edits) and restores the desired state automatically. Think of it like a thermostat: it constantly observes the environment and adjusts until the setpoint is reached. Continuous reconciliation reduces operational toil and improves resiliency by continuously observing, comparing, and correcting the cluster state.
The image illustrates a continuous integration setup involving a Kubernetes cluster that syncs with desired manifests, incorporating GitHub and an automation bot, alongside a thermostat displaying the number 78.

​
Declarative

Declarative configuration states what you want the system to look like (the desired state), not how to get there. A GitOps operator is responsible for making the cluster match that description. Imperative commands execute specific API calls and steps; declarative manifests describe the intended outcome. Imperative example (direct commands): 
kubectl create deployment nginx-deployment \
  --image=nginx:latest \
  --replicas=5

kubectl expose deployment nginx-deployment \
  --type=LoadBalancer \
  --port=80 \
  --target-port=80 \
  --name=nginx-service
Declarative example (YAML manifests stored in Git): Service (service.yml) 
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx-deployment
spec:
  type: LoadBalancer
  selector:
    app: nginx-deployment
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
Deployment (deployment.yml) 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      labels:
        app: nginx-deployment
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
A GitOps operator (for example, Flux or Argo CD) watches the repository and applies the YAML manifests to the cluster. Useful links:
Keeping the desired state in Git enables code review, CI checks, and an auditable history of configuration changes — essential for collaborative operations and compliance.

​
Desired state

The desired state is the canonical description of how your system should behave. A repository commonly contains a directory like manifests/ with YAML files for Deployments, Services, ConfigMaps, Ingresses, and more. Those files collectively define the desired state of your application and its infrastructure. Example repository tree:
  • manifests/deployment.yml
  • manifests/service.yml
  • manifests/configmap.yml
  • manifests/ingress.yml
Why desired state matters:
  • It provides a single, reviewable definition of intent.
  • Enables reproducible environments across clusters and teams.
  • Makes it possible to detect and correct divergences.
The image displays Kubernetes YAML manifest files, including deployment.yml, service.yml, configmap.yml, and ingress.yml, representing different components of a deployment setup. It shows a GitHub logo indicating the source directory for these manifests.

​
State drift

State drift happens when the actual cluster state diverges from the desired state in Git. Drift leads to unexpected behavior, complicates troubleshooting, and can open security or stability gaps. Example scenario:
  • Desired state in Git specifies 5 replicas for a Deployment (declared in deployment.yml).
  • Someone runs an imperative command that scales the Deployment to 3 replicas.
Deployment (desired in Git) 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
  labels:
    app: nginx-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      labels:
        app: nginx-deployment
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
Imperative change made in cluster 
kubectl scale deployment nginx-app --replicas=3
Now the cluster has three replicas while Git declares five — that divergence is state drift.
Avoid ad-hoc imperative changes in production clusters. They create drift that breaks the one source of truth model and can undermine automated reconciliation.

​
State reconciliation

State reconciliation detects drift and brings the actual state back in line with the desired state. Reconciliation is the GitOps control loop: Observe -> Diff -> Act.
  • Observe: the operator reads desired manifests from Git and inspects the running cluster.
  • Diff: it computes the differences between desired and actual states.
  • Act: it applies the needed changes to reconcile the cluster to the declared state.
Using Flux or Argo CD, the operator will detect the replica mismatch and create two additional Nginx pods to return the replica count to five. Why reconciliation matters:
  • Self-healing: automatic correction improves availability.
  • Consistency: ensures the running system matches declared configuration.
  • Reduced manual intervention: operators fix drift without human action.
The image illustrates a "State Reconciliation" process involving a circular flow of "Observe," "Diff," and "Act" to align the "Desired State" from Git with the "Actual State" in a Kubernetes cluster.

​
GitOps-managed software system

A GitOps-managed software system is any system (Kubernetes clusters, applications, or infrastructure) controlled via GitOps principles. The Git repository becomes the single source of truth for namespaces, RBAC, Helm charts, deployments, services, and add-ons (for example Prometheus). All changes are made by editing the repository; a GitOps operator ensures those changes are applied automatically.
The image illustrates a GitOps Managed Software System, showing the flow from Git repositories (with Kubernetes manifests, Helm charts, Terraform, and Ansible files) to a GitOps operator, which then manages deployments across cloud services like Azure, Google Cloud, AWS, and Kubernetes.

​
State store

The state store is the centralized repository holding the definitive desired state—most commonly Git. It contains all configuration and manifests, and acts as the authoritative record of system intent. Why a state store matters:
  • Single source of truth: Git is the authoritative record of system state.
  • History and audit: every change is tracked and reviewable.
  • Collaboration: teams use pull requests, code review, and branching workflows.
The image illustrates a diagram showing a Git-based single source of truth for managing configurations and code, involving developers, operators, and CI systems like Jenkins, with directories for Kubernetes manifests, Helm charts, Terraform, and Ansible.
Note: Some GitOps patterns use OCI artifact registries to store declarative artifacts (e.g., OCI images or bundles) and may treat those registries as a form of state store.

​
Feedback loop

The feedback loop closes the cycle between deployment and operation. It uses observability signals (metrics, logs, alerts) to inform stakeholders and to trigger fixes or rollbacks in Git. Typical feedback flow:
  1. GitOps operator deploys a new version from Git.
  2. Monitoring (Prometheus) detects increased error rates.
  3. Visualization (Grafana) surfaces the issue.
  4. Alertmanager sends notifications (email, Slack).
  5. Teams revert or fix the change in Git, triggering reconciliation back to a healthy state.
The image depicts a feedback loop in a software deployment process, showing interactions between a bot, a version control system, a Kubernetes cluster, and a monitoring stack (Prometheus, Grafana, Alert Manager). It illustrates pulling, deploying, adjusting, and informing stages within this loop.
Why the feedback loop matters:
  • Detect problems early using automated observability.
  • Close the loop from runtime signals back to the desired configuration.
  • Iterate quickly and safely using operational data.

​
Rollback

Rollbacks let you quickly undo problematic changes, either manually via Git or automatically via GitOps tooling. Common rollback methods:
MethodWhen to useExample
Git revertManual, precise undo while preserving historygit revert <commit-hash>
Automated rollbackConfigure GitOps tool to revert on failed health checks or failed deploysArgo CD or Flux health/rollback configurations
Example: revert a bad commit 
# Revert a bad commit (replace <commit-hash> with the actual hash)
git revert <commit-hash>
Example revert output: 
$ git revert o3u9n
[master s5e79] Revert "Config change"
 1 file changed, 1 deletion(-)
Some GitOps tools (for example Argo CD) can be configured to automatically revert to a known-good state when health checks fail or a deployment does not meet success criteria.
The image shows a rollback process flowchart, with steps from "Commit A" to "System back State A," including a "Commit B (Bad)" and "Revert" step.
Why rollback matters:
  • Rapid recovery from bad deployments or configuration mistakes.
  • Minimizes downtime and service disruption.
  • Encourages frequent deployments by providing a reliable safety net.

​
Key terms at a glance

TermShort definition
Continuous reconciliationOngoing loop that observes, diffs, and acts to keep systems aligned with Git
DeclarativeConfiguration style that specifies desired end state (YAML manifests)
Desired stateThe canonical configuration stored in the state store (usually Git)
State driftWhen actual cluster state differs from the desired state
State reconciliationProcess to detect drift and restore desired state
State storeCentral repository of manifests (typically Git or OCI registries)
Feedback loopObservability-driven cycle that informs changes in Git
RollbackReverting to a previous known-good state via Git or tooling

​
Summary

  • GitOps uses Git as the single source of truth for declarative configuration.
  • Continuous reconciliation (Observe → Diff → Act) keeps actual state aligned with desired state.
  • Declarative manifests express intent; GitOps operators apply and maintain that intent automatically.
  • State drift is detected and corrected through reconciliation.
  • The state store (usually Git) enables collaboration, history, and reproducibility.
  • Feedback loops and rollbacks provide operational safety and enable rapid, reliable iteration.

Watch Video