GitOps Explained: Managing Infrastructure and Deployments with Git

What Is GitOps?

GitOps is an operational model where every infrastructure change and every deployment is driven by a Git commit. Instead of running kubectl apply or clicking buttons in a dashboard, you update a YAML file in a repository and an automated system reconciles the actual state of your infrastructure with the desired state declared in Git.

The four core principles of GitOps are:

1. 1Declarative — describe *what* you want, not *how* to get there.
2. 2Versioned and immutable — all changes are commits; history is never rewritten.
3. 3Pulled automatically — an agent pulls from Git, rather than CI pushing to infrastructure.
4. 4Continuously reconciled — the agent detects and corrects drift between desired and actual state.

GitOps vs Traditional CI/CD

In a traditional pipeline, CI/CD pushes artifacts directly to servers or clusters. In GitOps, CI builds and tests, but the *deployment* is triggered by updating a manifest in Git.

# Traditional: CI pushes directly
kubectl set image deployment/app app=myimage:v2.1.0

# GitOps: update the manifest in Git and let the agent deploy
# Edit kubernetes/deployment.yaml, then:
git add kubernetes/deployment.yaml
git commit -m "chore: bump app image to v2.1.0"
git push origin main

The difference is subtle but powerful: Git becomes your audit log, rollback mechanism, and access-control layer all at once.

Structuring a GitOps Repository

A common pattern is to maintain a dedicated config repository (sometimes called an *ops repo*) separate from your application code:

config-repo/
├── environments/
│   ├── staging/
│   │   ├── app-deployment.yaml
│   │   └── app-service.yaml
│   └── production/
│       ├── app-deployment.yaml
│       └── app-service.yaml
└── shared/
    └── ingress.yaml

Your application CI pipeline (in the app repo) builds the image, pushes it to a registry, then opens a pull request against the config repo bumping the image tag. A reviewer approves the PR, and the GitOps agent applies the change.

GitOps with PandaStack

PandaStack is built around GitHub-first deployments, making it a natural fit for GitOps workflows. Every application you deploy on PandaStack is linked to a GitHub repository and branch. Pushing to that branch triggers a deployment — the Git commit *is* the deployment trigger.

# Connect your repo to PandaStack
npm install -g @pandastack/cli
panda login
panda deploy --repo your-org/your-app --branch main

For infrastructure-as-code, store your PandaStack configuration in a panda.yaml at the root of your repository:

# panda.yaml
name: my-web-app
type: container
branch: main
build:
  dockerfile: Dockerfile
  context: .
env:
  NODE_ENV: production
  PORT: "3000"
resources:
  cpu: 500m
  memory: 512Mi

Any change to panda.yaml committed to main is treated as an infrastructure change and triggers a reconciliation — true GitOps behaviour with zero additional tooling.

Branch-Based Environment Promotion

A clean GitOps pattern maps branches to environments:

# .github/workflows/promote.yml
name: Promote to Production

on:
  pull_request:
    types: [closed]
    branches: [main]

jobs:
  promote:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Tag release
        run: |
          git tag v$(date +%Y%m%d%H%M%S)
          git push origin --tags

• develop branch → staging environment
• Merged PR to main → production environment

This gives you a clean, auditable promotion flow: every production deployment is traceable to a specific pull request and review.

Benefits of GitOps

Auditability: git log shows exactly who changed what and when, including infrastructure changes.

Rollback: Rolling back means reverting a commit — a skill every developer already has.

# Rollback the last infrastructure change
git revert HEAD --no-edit
git push origin main

Consistency: Staging and production drift is impossible — both environments are defined by files in the same repo.

Security: Developers never need direct cluster or server access. The GitOps agent has credentials; humans have Git.

GitOps is not a tool — it is a discipline. Applied consistently, it transforms deployments from ad-hoc events into a reliable, transparent, and reversible engineering process.