🔄 Staging Is Not Dev: Understanding Git Workflows and Environments

One of the biggest confusions for junior developers: where do I code, where do I test, and how does Git fit in?

🤔 The Problem

Beginners think there are two places: their laptop and "the server."

Wrong. There are three.

🖥️ The Three Environments

🔑 Key Insight: Staging and Production run the same code. Only config changes.

🔀 The Flow (GitHub Flow)

feature/login ──► PR + Review ──► main ──► Deploy ──► 🧪 Staging
                                                          │
                                                    ✅ Pass?
                                                          │
                                              ┌─── Yes ────┴─── No ───┐
                                              ▼                       ▼
                                         🚀 Prod                  Fix on main

✅ No develop branch. ✅ No staging branch. ✅ Just main.

Feature branches are short-lived: Branch → Code → PR → Merge → Delete. Done.

❌ Why No Staging Branch?

Because Staging is a server, not a branch.

Deploy main to both environments. Only environment variables differ:

# settings.py (simplified)
import os

DEBUG = os.getenv("DEBUG", "False") == "True"

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.getenv("DB_NAME"),
        "HOST": os.getenv("DB_HOST"),
        "PASSWORD": os.getenv("DB_PASSWORD"),
    }
}

STRIPE_KEY = os.getenv("STRIPE_SECRET_KEY")

Same code. Different .env file. That's it.

Variables that typically change between environments:

• DEBUG
• DB_HOST
• STRIPE_KEY
• ALLOWED_HOSTS

⚠️ Note: the original source only listed these variable names — it didn't include the per-environment values (e.g. what DEBUG is set to in dev vs. staging vs. prod). Let me know the values if you'd like a full comparison table.

⚙️ The YAML Pattern (Agnostic)

Generic CI/CD pattern — adapt to GitHub Actions, GitLab CI, or whatever:

# Generic CI/CD Pattern (not vendor-locked)
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: |
          docker build -t myapp:${{ github.sha }} .

      - name: Deploy Staging
        env:
          SSH_KEY: ${{ secrets.STAGING_SSH_KEY }}
          HOST: staging.example.com
        run: |
          echo "Deploy to staging..."

      - name: Smoke Test
        run: |
          curl -f https://staging.example.com/health || exit 1

      - name: Deploy Production
        if: success()
        env:
          SSH_KEY: ${{ secrets.PROD_SSH_KEY }}
          HOST: prod.example.com
        run: |
          echo "Deploy to prod..."

🔑 Key Point: Build once, deploy twice. Same artifact, different config.

🚩 Feature Flags > Long-Lived Branches

Working on a feature for two weeks but keeping main deployable? Use a flag, not a branch:

# Simple Django (no library needed)
from django.conf import settings

def is_feature_enabled(request, feature_name):
    """Check if a feature flag is enabled for this user."""
    flags = getattr(settings, "FEATURE_FLAGS", {})
    return flags.get(feature_name, False)

# settings/production.py
FEATURE_FLAGS = {
    "new_dashboard": False,  # Flip to True when ready
    "beta_search": True,
}

✅ No branch needed. ✅ No merge conflict risk. ✅ Just flip a switch.

⚠️ Common Mistakes to Avoid

• ❌ Having both a dev branch and a main/prod branch
• ❌ Treating "staging" as a branch instead of a deployed environment
• ❌ Hardcoding environment-specific logic directly in code
• ❌ Letting feature branches live for weeks before merging

⚠️ Note: the original source's mistakes table was missing its second column (presumably "why it's a problem" or "what to do instead"). I've listed the mistakes above — happy to add explanations for each if useful.

📋 TL;DR Checklist

• ✅ One main branch. That's your single source of truth.
• ✅ Feature branches are disposable. Branch, code, PR, merge, delete.
• ✅ Staging = server, not branch. Deploy main to staging with staging config.
• ✅ Same code, different .env. Never hardcode environment-specific logic.
• ✅ Use feature flags for work-in-progress. Not long-lived branches.
• ✅ Build once, deploy twice. Same artifact, different host.

📚 Related Posts

• Building Real-Time Features with Django, HTMX & WebSockets
• Architecting a Production ERP: Lessons from an 11-Phase Django Build