Git Branching Model - Team Workflow

Visualized Scenario: The v1.0.2 Release Cycle

1. Development Phase

The team works on develop.
• feat/A and feat/B are merged.
• bug/X (dev issue) is fixed.
Result: develop is ready for release (12).

2. The Mirror Snap

We cut release/v1.0.2 from develop (13).
• Immediate Action: We sync this branch to uat and preprod.
• Safe Sync: We use --ff-only (Fast Forward) to ensure we don't overwrite manual changes.

3. QA & Hardening

Bug Y (UAT) and Bug Z (Preprod) are fixed directly on the release branch.
• Auto-Sync: Fixes are mirrored to UAT/Preprod and back-merged to develop.

4. Production

QA signs off.
• release merges to master (Tag v1.0.2).
• Release branch is deleted.

5. Hotfix (v1.0.3)

Critical fix in production.
• Cut release/v1.0.3-hotfix from master.
• Mirror, validate, and ship to master (v1.0.3).
• Final sync back to develop.

Standard Branching Strategy

Our workflow follows a "Mirrored GitFlow" methodology. Production candidates are isolated in a release branch, which strictly dictates the state of UAT and Preprod environments.

Branch	Role & Alignment
`master`	Production. Stable history. Represents what is currently live. All commits are tagged (e.g., `v1.0.2`).
`develop`	Integration Hub. Contains only current release features. Note: Future features must remain in pending MRs.
`release/vX.Y.Z`	Release Candidate. Cut from `develop`. The Single Source of Truth for UAT and Preprod.
`uat` & `preprod`	Read-Only Mirrors. These branches are fast-forwarded to match the active `release` branch.
`feat/*`	Features. Branch from `develop` → Merge to `develop`.
`bug/*`	Fixes. • Dev Phase: Target `develop`. • QA Phase: Target `release/v*` (Triggers Mirror + Sync).

Standard Release Flow

During release hardening, all fixes are committed directly to release, then mirrored forward and back-merged to develop once.

feat/* → develop

develop → release

release → uat

release → preprod

release → master (tag → production)

release → develop (to sync any updates)

Hotfix Flow

Critical production fixes follow a streamlined version of the release process for consistency and safety.

master → release/v*-hotfix

Apply fix on release branch

release/v*-hotfix → uat

release/v*-hotfix → preprod

release/v*-hotfix → master (tag)

release/v*-hotfix → develop

Safety Protocols

Mirror Integrity: Mirrors are updated only from release. If divergence occurs, uat/preprod are hard-reset to release.
The Boarding Gate: Do not merge v1.0.3 features into develop until release/v1.0.2 has been cut. Keep them as open Pull Requests.

The Mirror Invariant

release == uat == preprod

We strictly enforce that UAT and Preprod are identical copies of the Release branch. We never merge from UAT to Preprod; we push to both from Release.

Branch Types