Origin of GitOps — What Was Formalized and Why It Matters

Source: Dev.to | Jan 23, 2026 (UTC)

1. Introduction

In modern cloud-native systems, especially Kubernetes-based platforms, teams struggled with manual deployments, configuration drift, and unreliable rollbacks.
From this operational pain, a new approach emerged — GitOps.

GitOps is not a tool.
It is an operational model that defines how systems should be deployed and managed.

2. Who Introduced GitOps?

The term GitOps was introduced and formalized by Weaveworks around 2017.

Weaveworks engineers were operating Kubernetes clusters in production and noticed that the most reliable deployments shared common characteristics:

• Git was already being used as the source of configuration
• Pull requests were used for review
• Rollbacks were done via Git revert
• Manual kubectl changes caused incidents

Instead of treating these as isolated practices, they formalized them.

3. What Does “Formalized” Mean?

Formalization means:

Turning an informal, ad-hoc practice into a named, documented, repeatable operating model.

Before formalization

• Teams used Git differently
• Rules were implicit
• Knowledge was tribal
• Hard to teach or scale

After formalization

• Clear principles
• Shared vocabulary
• Repeatable process
• Tooling aligned to the model

This is similar to how Agile or DevOps became recognized practices.

4. The GitOps Principles (What Was Formalized)

Weaveworks defined four core principles:

1️⃣ Git as the Single Source of Truth

• Desired state lives in Git
• Nothing is changed outside Git

2️⃣ Declarative Configuration

• Systems are described, not scripted
• “What” instead of “how”

3️⃣ Pull-Based Reconciliation

• The system pulls changes from Git
• Humans and CI do not push directly to production

4️⃣ Continuous Enforcement

• Drift is detected
• Drift is corrected automatically or flagged

These principles together form GitOps.

5. Why GitOps Is an Idea (Not a Product)

GitOps:

• Has no binaries
• Has no vendor lock-in
• Can be implemented by many tools

It defines behavior, not software.

That is why GitOps is described as an operational model, not an application.

6. Why Kubernetes Made GitOps Practical

GitOps became powerful because Kubernetes is:

• Declarative
• API-driven
• Controller-based
• Continuously reconciling state

GitOps simply extends Kubernetes reconciliation to Git.

7. How Argo CD Fits In

Argo CD is a tool that implements GitOps for Kubernetes.

• Runs inside Kubernetes
• Watches Git repositories
• Compares desired vs actual state
• Synchronizes automatically

Important:

Argo CD did not invent GitOps — it implements it.

8. Timeline Summary

2005 → Git (version control) 2014 → Kubernetes (declarative platform) 2017 → GitOps term formalized (Weaveworks) 2018+ → Tools like Argo CD and Flux

Enter fullscreen mode

Exit fullscreen mode