Git Management

Git Branching and Release Flow

This repo uses three long-lived branches: dev, staging, and prod. The flow is designed to keep development moving quickly while ensuring stable releases.

Branches

• dev: Active development branch. All feature work targets this branch.
• staging: Pre-production branch. Mirrors what we intend to ship next.
• prod: Production branch. Always reflects what is live.

Feature Development Flow

1. Branch off dev

   • Create feature branches from dev.
   • Example: feature/add-event-end-date

2. Open a PR into dev

   • Run local tests.
   • CI must pass.
   • Code owner reviews required.

3. Squash merge into dev

   • Keeps history clean and focused.

Diagram: Feature Branch Flow

graph TD
  A[dev] -->|branch| B(feature/xyz)
  B -->|PR & squash merge| A

Loading

Release Flow (Dev → Staging → Prod)

1. PR: dev → staging

   • This is a commit merge (no squash).
   • Preserves full commit history for release tracking.

2. Test on staging apps

   • Validate behavior in staging environment.

3. PR: staging → prod

   • Also a commit merge (no squash).
   • This is the production release.

Diagram: Release Promotion

graph LR
  dev -->|commit merge PR| staging -->|commit merge PR| prod

Loading

Back-Merge Flow (Prod → Staging → Dev)

After production deployment:

1. Commit merge prod → staging (no PR)

git fetch origin
git switch staging
git pull
git merge origin/main
git push origin staging

2. Commit merge staging → dev (no PR)

git fetch origin
git switch dev
git pull
git merge origin/staging
git push origin dev

This ensures all release metadata and hotfixes are fully synced downstream.

Diagram: Back-Merge

graph LR
  prod -->|commit merge| staging -->|commit merge| dev

Loading

---

Notes / Rationale

• Squash merges into dev keep feature work tidy.
• Commit merges between long-lived branches preserve release history.
• Back-merging after prod prevents drift and keeps branches aligned.