Git, branches & deploys

We run two deploy models. Knowing which one you’re in prevents 90% of mistakes.

Changing a marketing website?

flowchart TD
  A1[Branches: main + staging ONLY] --> A2[Work on staging → verify the preview]
  A2 --> A3[Owner approval for customer-facing changes]
  A3 --> A4[Merge to main = PRODUCTION deploy]

Changing the ops dashboard?

flowchart TD
  B1[Branch: master ONLY] --> B2[Commit + push = deploy]
  B2 --> B3[No approval gate — internal tool, always push live]

The rules

1. Marketing sites: exactly two branches — main + staging. Never create any other branch (no feature/fix/throwaway branches). They drift and cause mistakes; delete strays on sight. main is the source of truth; staging is always a clean copy of it.
2. Ops dashboard: exactly one branch — master. Push to it and it deploys. Absolute rule, including for automated agents.
3. Pushing a marketing site’s main is a live production deploy — verify on the staging preview first, and get explicit approval for customer-facing changes. “Push to staging” never implies production.
4. The dashboard is the opposite — always push live, no review step. It’s internal.
5. GitHub is the source of truth. All repos live under the OwnerOperated account. Local clones live under C:\Users\alexb\Glass projects\.
6. Local first — never edit production servers directly. Everything goes through git so the repo stays authoritative.
7. Never commit build output — no dist/, no node_modules/. The platforms build from source.

Verb glossary

Verb	Meaning
”push” / “push live”	Commit, push, and deploy per that project’s rules
”deploy”	Deploy only — the code is already pushed. If the environment is ambiguous, ask — never assume production.

Working with Claude Code

• Open Claude in the specific repo’s folder so its rules file (CLAUDE.md) auto-loads — never work from the home directory.
• On launch, a sync-check reports whether the local clone is [UP TO DATE] or [BEHIND] the remote — never work on a stale copy.