In GitOps, how is the Desired State stored?

GitOps mandates that the canonical “desired state” of the system be kept in a version-control repository (typically Git). Each commit produces an immutable snapshot of the manifest set, while the Git history inherently provides complete versioning. This guarantees reproducibility, auditability, and the ability to roll back to any prior known-good configuration—core goals of GitOps practice.

A. Mutability contradicts GitOps; commits must be immutable to ensure reliable rollback and audit trails.
B. GitOps forbids out-of-band changes; all modifications must flow through pull requests to the repo, not made directly on live clusters.
C. Git stores every commit, not just the latest state; losing history would undermine audit and rollback capabilities.

1. CNCF GitOps Working Group, “Principles of GitOps”, v1.0, Apr 2021 – Section “Declarative desired state is versioned and immutable” (p. 2).

2. Weaveworks, “GitOps – Operations by Pull Request”, Whitepaper, 2017 – p. 2, ¶3: “Git provides an immutable, versioned single source of truth for infrastructure.”

3. The Linux Foundation, “Introduction to GitOps” (LFS169x), Chapter 2, “Desired State in Git: immutability & full history”.

4. University of Michigan ITS, “DevOps with Cloud Native Tools” course notes, Week 4, Slide 11: “Desired state kept in Git: commit history is immutable; every change is versioned.”