There is a production change in your organization that was made directly against the cluster at 2 PM, by someone who knew the right command, to fix something urgent. It worked. It is also undocumented, unreviewed, and invisible to the next engineer who looks at the supposed source of truth and finds it no longer matches reality. The cluster and the config repository have drifted, and nobody knows by how much.
This is more than a one-off manual change. It is the operational gap GitOps is meant to close.
GitOps beyond the hype is not about a specific tool. It is an operating model where the desired state of your system lives in git, a controller continuously reconciles reality to match it, and every change flows through a reviewed commit, so the repository is the source of truth and the system cannot quietly drift from it.
However, many teams adopt a GitOps tool without adopting the operating model, still making manual changes on the side, and get the dashboard without the discipline.
If you are a platform or engineering leader weighing GitOps, the intent of this article is:
- Define what GitOps actually changes in operations
- Walk through git as the source of truth and reconciliation
- Lay out the discipline that makes GitOps deliver
To do that, let's start with the basics.
Why Functional Infrastructure Fails Due Diligence
Inside a 90-day sprint that took a flagged round to a $28M close.
What Is GitOps? The Basic Definition
At a high level, GitOps is an operating model where the system's desired state is declared in git, an automated controller continuously reconciles the running system to that declared state, and all changes are made by committing to git rather than by acting on the system directly.
To compare:
If manual operations is steering a car by constantly adjusting the wheel, GitOps is setting the destination and letting the system drive toward it, correcting drift automatically. You change where you are going by changing the destination, not by grabbing the wheel mid-route.
Why Is GitOps Necessary?
Issues that GitOps addresses or resolves:
- Eliminating configuration drift between the repo and reality
- Making every change reviewed, auditable, and reversible
- Replacing ad hoc manual operations with a declarative source of truth
Resolved Issues by GitOps
- Keeps the running system continuously matching declared state
- Provides a git history as a full audit trail of changes
- Makes rollback a git revert rather than a manual scramble
Core Components of GitOps
- Desired state declared in git
- A reconciliation controller enforcing that state
- Changes made via reviewed commits, not direct action
- Drift detection and correction
- Auditability through git history
Modern GitOps Tools
- Argo CD and Flux for Kubernetes reconciliation
- Git providers for review, history, and approval
- Kustomize and Helm for declarative configuration
- Policy checks in the commit pipeline
- Secrets handling integrated with the GitOps flow
These tools implement GitOps, but the value comes from the operating model: git as truth and no changes outside it.
Other Core Issues They Will Solve
- Provide a clear, reviewable record of who changed what and when
- Make environment recreation reliable from the declared state
- Reduce the risk of undocumented, irreproducible production changes
Importance of GitOps in 2026
GitOps matters more as systems grow declarative and auditability tightens. Four reasons explain why it matters now.
1. Drift is a silent operational risk.
Manual changes that diverge from the declared state make the system unpredictable and recovery uncertain. Reconciliation removes that drift.
2. Auditability is now expected.
Knowing who changed what, when, and why is a baseline requirement. Git history provides it naturally; manual operations do not.
3. Reproducibility depends on declared state.
Recreating an environment reliably requires the desired state to live somewhere authoritative. GitOps makes git that place.
4. The tool without the model gives little.
Teams that adopt a GitOps controller but keep making manual changes get the appearance of GitOps without the drift-free, auditable reality.
Traditional vs. Modern Operations
- Manual changes to the system vs. changes via reviewed git commits
- Drift between intent and reality vs. continuous reconciliation
- Unclear change history vs. full audit through git
- Manual rollback vs. revert the commit
In summary: GitOps makes git the authoritative source of truth and the system continuously match it, replacing ad hoc operations.
Details About the Core Components of GitOps: What Are You Designing?
Let's go through each element.
1. Declared State Layer
Where intent lives.
State decisions:
- Desired state declared in git
- Configuration as code, reviewed
- One authoritative source per environment
2. Reconciliation Layer
How reality is kept in line.
Reconciliation decisions:
- Controller continuously enforcing declared state
- Drift detected and corrected automatically
- Manual divergence prevented or alerted
3. Change Layer
How changes are made.
Change decisions:
- Changes via reviewed commits only
- Direct system action disallowed
- Approval in the commit workflow
4. Audit Layer
How history is captured.
Audit decisions:
- Git history as the change record
- Who, what, when, and why visible
- Linked to review and approval
5. Recovery Layer
How rollback works.
Recovery decisions:
- Rollback by reverting the commit
- Reconciliation restoring known-good state
- Environment recreation from declared state
Benefits Gained from Git as Source of Truth
- A system that continuously matches its declared state, free of drift
- A full audit trail of every change through git history
- Rollback and environment recreation that are reliable, not heroic
How It All Works Together
The desired state of each environment is declared in git. A reconciliation controller continuously compares the running system to that declared state and corrects any drift, so a manual change made on the side is either prevented or pulled back to match the repository. Every intended change is made by committing to git, reviewed and approved before it merges, and recorded in the history with who, what, when, and why. To roll back, you revert the commit and let reconciliation restore the known-good state. To recreate an environment, you apply the declared state. Operations becomes declarative, auditable, and reproducible, and the repository and reality no longer drift apart.
Common Misconception
GitOps is just using a tool like Argo CD or Flux.
GitOps is an operating model: git as the source of truth, continuous reconciliation, and no changes outside git. A controller is necessary but not sufficient. Teams that keep making manual changes get the tool without the drift-free, auditable benefits.
Key Takeaway: The tool enables GitOps; the discipline of never changing the system outside git is what delivers it. Manual side-changes defeat the whole model.
Real-World GitOps in Action
Let's take a look at how GitOps operates with a real-world example.
We worked with a team whose cluster and config repo had drifted through manual changes, with these constraints:
- Make git the authoritative source of truth
- Eliminate drift through continuous reconciliation
- Gain a full audit trail of changes
Step 1: Declare State in Git
Put the desired state under version control.
- Configuration declared as code in git
- One authoritative source per environment
- Reviewed like any code
Step 2: Enable Reconciliation
Let a controller enforce the declared state.
- Controller continuously reconciling
- Drift detected and corrected
- Manual divergence surfaced
Step 3: Route All Changes Through Git
Disallow direct changes to the system.
- Changes via reviewed commits only
- Direct cluster access restricted
- Approval in the workflow
Step 4: Use Git History for Audit
Capture every change with context.
- History as the change record
- Who, what, when, and why visible
- Linked to review
Step 5: Make Rollback a Revert
Recover by reverting commits.
- Rollback via git revert
- Reconciliation restoring known-good
- Environment recreation from declared state
Where It Works Well
- Desired state declared in git as the single source of truth
- Continuous reconciliation correcting drift automatically
- All changes via reviewed commits, with git as the audit trail
Where It Does Not Work Well
- Adopting a GitOps tool but still making manual changes
- No reconciliation, so the repo and reality drift
- Direct production access that bypasses the git workflow
Key Takeaway: The operations that stay predictable and auditable are the ones where git is truth and reconciliation enforces it, not the ones that run a GitOps tool while still changing the system by hand.
Common Pitfalls
i) Tool without the model
Running a reconciliation controller while still making manual changes gives the appearance of GitOps without the benefits. Commit to the operating model.
- Make git the only path to change
- Restrict direct system access
- Let reconciliation enforce state
ii) No drift correction
Detecting drift but not correcting it leaves the repo and reality diverging. Reconciliation must actually enforce the declared state.
iii) Bypassing review
Changes committed without review lose the audit and quality benefits. Route changes through reviewed commits.
iv) Secrets mishandled
Putting secrets in git plainly is a leak. Integrate proper secrets handling with the GitOps flow.
Takeaway from these lessons: Most GitOps disappointments trace to adopting the tool without the discipline, not to GitOps itself. Make git the only path to change and let reconciliation enforce it.
GitOps Best Practices: What High-Performing Teams Do Differently
1. Make git the only path to change
Disallow direct changes to the system. The drift-free, auditable benefits depend on every change flowing through git.
2. Enforce, do not just detect, drift correction
Let the controller actively reconcile reality to declared state, so a manual change is pulled back rather than merely noticed.
3. Review every change
Route changes through reviewed commits so quality and audit come for free with the workflow.
4. Handle secrets properly
Integrate secrets management with the GitOps flow rather than committing secrets in plaintext.
5. Treat rollback as a revert
Build the habit of recovering by reverting commits and letting reconciliation restore state, rather than manual intervention.
Logiciel's value add is helping teams declare state in git, enable enforcing reconciliation, route all changes through review, and integrate secrets, so GitOps delivers drift-free, auditable operations rather than just a dashboard.
Takeaway for High-Performing Teams: Focus on the operating model, not the tool. GitOps delivers when git is the only source of truth and reconciliation enforces it; manual side-changes quietly defeat the entire point.
Signals You Are Doing GitOps Correctly
How do you know the GitOps adoption is set up to succeed? Not in running a controller, but in whether the model holds. Below are the signals that distinguish real GitOps from a tool bolted onto manual operations.
The repo matches reality. The team can trust that the declared state in git reflects the running system, because reconciliation enforces it.
Changes go through git. The team can show that production changes are reviewed commits, not direct actions, with direct access restricted.
History is the audit trail. The team can answer who changed what, when, and why from git history alone.
Drift is corrected, not just seen. A manual change is pulled back to the declared state automatically.
Rollback is a revert. The team recovers by reverting commits and letting reconciliation restore known-good state.
Adjacent Capabilities and Connected Work
This work does not exist in isolation. GitOps depends on, and feeds into, several adjacent capabilities. Building one without thinking about the others is the most common scoping mistake.
In most enterprise programs, GitOps shares infrastructure with the git provider, the CI pipeline, and the secrets management system. It shares team capacity with platform engineering, SRE, and the application teams whose deployments it governs. And it shares leadership attention with whatever the next delivery or reliability initiative is on the roadmap. Naming these adjacencies upfront helps the program scope realistically and helps leadership see the work as a portfolio rather than a one-off project.
The most common mistake in adjacent-capability scoping is treating each adjacency as someone else's problem. The review workflow in the git provider is your problem. The secrets integration is your problem. The access controls that prevent direct changes are your problem. Pretending otherwise pushes work to teams that did not plan for it, and the work returns to you later as drift or a leak. Own the adjacencies you depend on; partner with the teams that own them; share the timeline.
Conclusion
GitOps, beyond the hype, changes operations by making git the source of truth and the system continuously match it. The discipline that delivers it is the same discipline behind any reliable process: declare the intent, enforce it automatically, and route every change through review.
Key Takeaways:
- GitOps is an operating model, not a specific tool
- Git is the source of truth, and reconciliation enforces it
- The benefits depend on never changing the system outside git
Adopting GitOps well requires source-of-truth, reconciliation, and discipline. When done correctly, it produces:
- A system that continuously matches declared state, free of drift
- A full audit trail through git history
- Reliable rollback and environment recreation
- Operations that are declarative, auditable, and reproducible
Why Boards Reject Infrastructure Spending Cases
Inside a financial-frame business case that turned a 14-month stall into a 45-minute board approval.
What Logiciel Does Here
If your cluster and config repo drift through manual changes, declare state in git, enable enforcing reconciliation, and route every change through reviewed commits.
Learn More Here:
- GitOps and Deployment Pipeline Services
- Progressive Delivery: Canaries, Blue-Green, and Feature Flags
- Policy as Code: Enforcing Standards Without Slowing Teams
AtLogiciel Solutions, we work with platform and engineering leaders on GitOps operating models, reconciliation, and delivery pipelines. Our reference patterns come from production GitOps deployments.
Explore what GitOps actually changes in your operations.
Frequently Asked Questions
What is GitOps?
An operating model where the system's desired state is declared in git, an automated controller continuously reconciles the running system to that state, and all changes are made by committing to git rather than acting on the system directly. Git becomes the source of truth.
Is GitOps just using Argo CD or Flux?
No. Those tools implement reconciliation, but GitOps is the operating model around them: git as the single source of truth, continuous reconciliation, and no changes made outside git. Running the tool while still making manual changes gives the appearance without the benefits.
What does GitOps actually change in day-to-day operations?
Changes are made by reviewed commit rather than direct action; the running system continuously matches the declared state through reconciliation; git history becomes the audit trail; and rollback becomes reverting a commit. Drift between intent and reality is eliminated.
How does GitOps handle rollback?
You revert the commit that introduced the change, and the reconciliation controller restores the running system to the previous known-good declared state. Recovery is a git operation rather than a manual intervention on the system.
What is the biggest mistake in adopting GitOps?
Adopting the tool without the operating model, continuing to make manual changes to the system on the side. This reintroduces drift and defeats the auditability and reproducibility that make GitOps valuable. Git must be the only path to change.
