GitOps Cheat Sheet

Updated 2026-04-28

Next Topic: Golden Path Design and Developer Self-Service Workflows Cheat Sheet

🧠Study flashcards on this topic112 cards · spaced repetition→

GitOps is a declarative, Git-based operational framework for managing infrastructure and applications, where Git serves as the single source of truth for the entire system's desired state. Born from Kubernetes workflows, GitOps combines version control, automation, and continuous reconciliation to ensure what's running in your cluster always matches what's defined in Git — making deployments auditable, reproducible, and easily reversible. Unlike traditional CI/CD where pipelines push changes, GitOps operators pull changes from Git and continuously enforce the declared state, enabling self-healing infrastructure that automatically corrects drift when manual changes occur. As of 2026, over 64% of enterprises use GitOps as their primary delivery mechanism, with the ecosystem expanding beyond Kubernetes into full infrastructure management via tools like Crossplane, Terraform, and OpenTofu.

What This Cheat Sheet Covers

This topic spans 22 focused tables and 145 indexed concepts, 112 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core PrinciplesTable 2: GitOps ToolsTable 3: Repository Structure PatternsTable 4: Deployment ModelsTable 5: Sync and ReconciliationTable 6: Progressive Delivery StrategiesTable 7: Manifest ManagementTable 8: Secrets ManagementTable 9: ArgoCD FeaturesTable 10: FluxCD FeaturesTable 11: Security Best PracticesTable 12: Policy Enforcement ToolsTable 13: Monitoring and ObservabilityTable 14: Multi-Cluster PatternsTable 15: Image Update AutomationTable 16: Environment PromotionTable 17: Notification and AlertingTable 18: CI/CD IntegrationTable 19: Troubleshooting and DebuggingTable 20: Advanced ConceptsTable 21: GitOps Anti-PatternsTable 22: Infrastructure GitOps

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Principles

The four pillars the OpenGitOps project distilled the whole practice down to: your system is described declaratively, that description is versioned and immutable in Git, agents pull it automatically, and they continuously reconcile reality back to it. Every tool and pattern later in this sheet is ultimately an implementation of these four ideas.

Principle	Example	Description
Declarative	`apiVersion: apps/v1` `kind: Deployment` `spec:` `replicas: 3`	System's entire desired state is expressed declaratively in Git using configuration files (YAML, JSON) — defines what should exist, not how to create it.
Versioned and immutable	Git commit: `f3a9b12` → rollback via `git revert f3a9b12`	• All state declarations are stored in Git with full version history • every change is tracked, auditable, and reversible using standard Git operations.
Pulled automatically	ArgoCD agent polls Git repo every 3 minutes	Software agents running inside the cluster continuously pull changes from Git — eliminates the need to store cluster credentials in external CI systems (pull model vs push).
Continuously reconciled	Operator detects `replicas: 2` (actual) ≠ `replicas: 3` (Git) → auto-scales	Agents continuously compare actual cluster state against Git-declared state and automatically correct drift — ensures self-healing without manual intervention.

Table 2: GitOps Tools

The operators and platforms that actually do the reconciling. ArgoCD and FluxCD are the two heavyweights you'll choose between, but the rest of the table fills in the surrounding toolkit — progressive-delivery controllers, image updaters, promotion orchestrators, and full CI/CD platforms — so you can see where each one fits in a real pipeline.

Tool	Example	Description
ArgoCD	`argocd app create myapp --repo https://github.com/org/repo` `--path manifests --dest-server https://kubernetes.default.svc`	• Declarative GitOps CD tool for Kubernetes with a powerful web UI, multi-cluster support, SSO integration, and built-in health assessment • most widely adopted — used in ~60% of surveyed Kubernetes clusters (CNCF 2025).

The rest of this section is part of the full cheat sheet

Table 3: Repository Structure Patterns

How you lay out your Git repos shapes how painful — or painless — multi-environment GitOps becomes. The patterns here run from the folder-per-environment overlay layout most teams settle on, through monorepo versus polyrepo trade-offs and ArgoCD's App-of-Apps and ApplicationSet scaling tricks, down to the branch-per-environment approach that's now firmly an anti-pattern.

Pattern	Example	Description
Environment per folder	`base/` `overlays/dev/` `overlays/staging/` `overlays/production/`	• Single branch with folders for each environment using Kustomize overlays • preferred pattern for most teams as it avoids branch management complexity and keeps all history in one place.

The rest of this section is part of the full cheat sheet

Table 4: Deployment Models

The dividing line between "true GitOps" and everything else comes down to who initiates the change. A pull-based operator living inside the cluster never lets credentials leave, which is the security win at the heart of GitOps; push-based pipelines are simpler but hand cluster keys to your CI system. The hybrid sits in between.

Model	Example	Description
Pull-based	ArgoCD/Flux agent inside cluster polls Git every 3 min	• In-cluster operator continuously pulls changes from Git • no cluster credentials leave the cluster, improving security • true GitOps model.

The rest of this section is part of the full cheat sheet

Table 1: Core Principles

Principle	Example	Description
Declarative	`apiVersion: apps/v1` `kind: Deployment` `spec:` `replicas: 3`	System's entire desired state is expressed declaratively in Git using configuration files (YAML, JSON) — defines what should exist, not how to create it.
Versioned and immutable	Git commit: `f3a9b12` → rollback via `git revert f3a9b12`	• All state declarations are stored in Git with full version history • every change is tracked, auditable, and reversible using standard Git operations.
Pulled automatically	ArgoCD agent polls Git repo every 3 minutes	Software agents running inside the cluster continuously pull changes from Git — eliminates the need to store cluster credentials in external CI systems (pull model vs push).
Continuously reconciled	Operator detects `replicas: 2` (actual) ≠ `replicas: 3` (Git) → auto-scales	Agents continuously compare actual cluster state against Git-declared state and automatically correct drift — ensures self-healing without manual intervention.

Table 2: GitOps Tools

Tool	Example	Description
ArgoCD	`argocd app create myapp --repo https://github.com/org/repo` `--path manifests --dest-server https://kubernetes.default.svc`	• Declarative GitOps CD tool for Kubernetes with a powerful web UI, multi-cluster support, SSO integration, and built-in health assessment • most widely adopted — used in ~60% of surveyed Kubernetes clusters (CNCF 2025).

Table 3: Repository Structure Patterns

Pattern	Example	Description
Environment per folder	`base/` `overlays/dev/` `overlays/staging/` `overlays/production/`	• Single branch with folders for each environment using Kustomize overlays • preferred pattern for most teams as it avoids branch management complexity and keeps all history in one place.

Table 4: Deployment Models

Model	Example	Description
Pull-based	ArgoCD/Flux agent inside cluster polls Git every 3 min	• In-cluster operator continuously pulls changes from Git • no cluster credentials leave the cluster, improving security • true GitOps model.