Skip to content

Git & Branching Protocol

Overview

This document defines the "Library Control" for our code. It ensures that changes are drafted, reviewed, and rehearsed before being published to the live environment.

1. The Four Tiers

Tier Branch Environment Purpose
1. Workbench feature/* Local Emulator Creation, Experimentation, Breaking Changes.
2. Integration dev Cloud Dev Shared Preview, Integration Testing, "The Printer".
3. Rehearsal stg Cloud Staging User Acceptance Testing (UAT), Final Verification.
4. Live main Production The Public Record.

2. Standard Workflow

Step 1: Check Out (Create Feature)

Never work directly on tst or main. Always create a fresh workspace.

git checkout -b LOC/marketing/my-new-idea

Step 2: The Draft (Commit)

Save your work frequently.

git add .
git commit -m "feat(auth): implemented login tabs"

Step 3: Submission (Push & PR)

Push your feature to the server.

git push origin feature/my-new-idea

Action: Open a Pull Request (PR) on GitHub targeting the dev branch.

Step 4: The Build (CI/CD)

When code lands in dev, stg, or main, the Deployment Droid (GitHub Actions) automatically builds and deploys the site.

  • Success: The site is updated.
  • Failure: The deployment stops; the live site is protected.

3. Deployment Triggers

  • Push to dev → Deploys to https://dev.singulardream.org (Example)
  • Push to stg → Deploys to https://stg.singulardream.org
  • Push to main → Deploys to https://singulardream.org

4. Emergency Protocol (Hotfix)

If Production is on fire:

  1. Create hotfix/urgent-repair from main.
  2. Fix the bug.
  3. PR directly to main (and backport to dev).

Version History

Version Date Author Change
0.1.0 2026-01-29 Antigravity Initial Audit & Metadata Injection