What Is GitOps and How Does It Work?

It is Friday afternoon and production is behaving strangely. Someone asks: “What changed?” One engineer ran a kubectl command last week. Another edited a config in the cloud console. A pipeline deployed something on Tuesday. Nobody has the full picture, and rolling back means guessing.

GitOps exists to make that question easy to answer. Every change to your running systems starts as a commit in Git, and software continuously makes the environment match what Git says. If you want to know what changed, you read the Git history. If you want to undo it, you revert the commit.

This guide explains what GitOps is, shows the workflow in a simple diagram, covers the 4 principles behind it and gives you a practical path to start.

What GitOps means

GitOps is an operating model for infrastructure and application delivery built on 2 ideas:

1. Git is the single source of truth. The desired state of your environment, such as which app versions run, how many replicas, which config, is stored as declarative files in a Git repository.
2. An agent keeps reality in sync. A tool running in or near your environment watches the repository and automatically applies changes, then keeps checking that the live state still matches.

The term was popularized by Weaveworks around 2017, and it is now standardized by the OpenGitOps project under the Cloud Native Computing Foundation (CNCF). It is most common with Kubernetes, but the same idea applies to any system you can describe declaratively.

If Git itself is new to you, start with Git for beginners, then come back.

The 4 GitOps principles

The OpenGitOps project defines GitOps with 4 principles (version 1.0.0):

The last 2 are what separate GitOps from “we keep our YAML in Git.” Storing files in Git is good hygiene. Having an agent that pulls those files and continuously corrects drift is GitOps.

Key takeaway: In GitOps, you never change production directly. You change Git, and an automated agent changes production to match. Git history becomes your deployment log, and git revert becomes your rollback button.

How GitOps works: a simple workflow

Here is the typical flow for a Kubernetes application:

text Developer App repo CI pipeline --------- -------- ----------- 1. Push code -------> main branch -------> 2. Build, test, scan 3. Push image v2.4 to registry | v Config repo <------- 4. Open PR: image tag (desired state) v2.3 -> v2.4 | 5. Review and merge PR | v GitOps agent (in cluster) 6. Pulls new desired state 7. Applies changes to cluster 8. Keeps comparing live vs desired; fixes drift or alerts | v Kubernetes cluster (running v2.4)

Step by step:

1. A developer pushes application code.
2. Continuous integration builds the code, runs tests and security scans.
3. CI pushes a new container image to a registry.
4. CI (or a bot) opens a pull request in the config repository updating the image tag.
5. A teammate reviews and merges the pull request. This is the deployment approval.
6. The GitOps agent inside the cluster notices the new commit and pulls it.
7. The agent applies the change, for example by rendering a Helm chart or Kustomize overlay.
8. The agent keeps comparing the cluster with Git. If someone changes the cluster by hand, the agent either reverts it or flags the application as out of sync.

Many teams keep application code and deployment configuration in separate repositories, so access controls and history stay clean. Smaller teams often start with a single repo and split later.

Push-based CI/CD vs GitOps

Traditional pipelines are push-based: the CI/CD server holds cluster credentials and runs deployment commands. GitOps is pull-based: the agent inside the environment fetches changes. Our CI/CD explainer covers the traditional model in depth.

GitOps doesn’t replace CI. You still need CI to build, test and package. GitOps replaces the deployment half of the pipeline, the “CD” in continuous delivery.

Popular GitOps tools

The 2 best-known GitOps tools for Kubernetes are both CNCF graduated projects:

• Argo CD describes itself as a declarative GitOps continuous delivery tool for Kubernetes. It runs as a controller, compares live state with Git, marks applications “OutOfSync” when they drift and can sync automatically or manually. It supports Helm charts, Kustomize, Jsonnet and plain YAML, and it has a well-known web UI.
• Flux is a set of Kubernetes controllers that reconcile clusters with Git repositories, Helm repositories and OCI registries. The CNCF lists Flux as graduated since November 30, 2022.

Both work with Helm charts, so you can keep using charts you already have. Several managed Kubernetes services now offer one of these tools as a built-in or add-on option.

Benefits and trade-offs

Benefits:

• Clear audit trail. Who changed what, when and why lives in Git history and pull request comments.
• Fast, safe rollback. Revert a commit and the agent rolls the environment back.
• Less credential exposure. CI systems no longer need production cluster credentials.
• Drift control. Manual “quick fixes” don’t silently pile up.
• Easier disaster recovery. You can rebuild a cluster by pointing a new agent at the same repository, as long as data is backed up separately.

Trade-offs:

• Secrets need extra tooling. You can’t store plain-text secrets in Git. Teams use tools such as Sealed Secrets, SOPS or an external secrets operator connected to a vault.
• Repo structure takes planning. Multiple environments, clusters and teams can make repositories messy without clear conventions.
• Not everything is declarative. Database migrations, one-off jobs and some cloud resources need extra patterns.
• Learning curve. Teams used to running commands directly need to adjust habits.

Where to start with GitOps

1. Pick one non-critical app and one cluster. A staging environment is ideal.
2. Make its configuration fully declarative. Put the Kubernetes manifests, Helm values or Kustomize overlays in a dedicated Git repository.
3. Protect the main branch. Require pull request reviews, as described in our guide to Git branching strategies.
4. Install Argo CD or Flux in the cluster and point it at the repository. Start with manual sync so the team can see what the agent would change.
5. Turn on automated sync once the team trusts the diffs, and decide whether drift should be auto-reverted or only reported.
6. Update CI so it ends by opening a pull request with the new image tag, instead of deploying directly.
7. Solve secrets early with an approved secrets tool, before anyone is tempted to commit a password.
8. Expand to production and more apps once the pattern works. Combine it with progressive delivery for safer rollouts.

GitOps fits naturally with infrastructure as code and with platform engineering, where a central team gives developers a paved path to production.

Conclusion

GitOps turns Git into the control panel for your environments. You describe the desired state in files, review changes through pull requests, and let an agent pull and apply them while continuously fixing drift. The payoff is a clear history of every change, simpler rollbacks and fewer credentials scattered around your pipelines. Start small with one app, one cluster and one repository, and grow from there.

Sources

• OpenGitOps: GitOps principles v1.0.0 — the 4 principles: declarative, versioned and immutable, pulled automatically, continuously reconciled
• Argo CD documentation — how Argo CD compares live and desired state, sync behavior and supported formats
• Flux documentation — Flux controllers and sources
• CNCF: Flux project page — Flux graduated maturity status and dates