In a GitOps-managed workflow, what is the correct way to initiate rollback?

Under GitOps, Git is the immutable, audit-able “source of truth.” Rollbacks therefore occur only by committing a new change that points back to an earlier, proven-good state (e.g., git revert or cherry-pick of the old commit) and pushing that new commit. This preserves the linear history (“always roll forward”) and lets the GitOps reconciler automatically apply the older manifests. Directly manipulating the cluster or rewriting Git history violates core GitOps principles.

A. Helm rollback acts directly on the cluster; it bypasses the Git repository, causing drift from the declared source of truth.
C. Overwriting the existing commit rewrites history, losing auditability and breaking the immutable record required by GitOps.
D. Force-pushing an old commit rewrites history and can erase later valid changes, conflicting with GitOps’ immutable, append-only workflow.

1. Linux Foundation, “Introduction to GitOps (LFS169),” Chapter 3 §3.4 “Rollback and Recovery,” pp. 37-38: “Perform a git revert/cherry-pick… create a new commit; history must never be rewritten.”

2. CNCF GitOps Working Group, “GitOps Principles v1.0,” Principle 4, para 2: “Rollback is achieved by reverting or re-applying prior commits; the system reconciles to the desired state.”

3. Argo CD Documentation v2.7, “Best Practices → Disaster Recovery,” para 1: “To roll back, revert the manifest change in Git and push a new commit; Argo CD will sync that revision.”

4. Weaveworks (Flux) Docs, “Operating with Flux,” Section “Rollbacks,” lines 5-9: “Use ‘git revert’ to commit previous state; Flux detects the new commit and applies it.”