Version Control, Branches & History

Developer

Repository & history

The project uses a Git-based workflow with history split across a legacy state and the current V&B-managed repository.

Earlier development activity included a separate legacy branch structure (server-updates) which acted as the primary production-aligned branch at the time. This branch is now deprecated and exists only as historical context. It also reflects a period where portions of production changes were not consistently committed into version control.

The current repository state is maintained as the source of truth, with full production alignment handled through controlled merges into main.

Branching strategy

The project follows a lightweight feature-branch workflow:

main acts as the primary integration branch and production reference.
Feature branches are created only when a change cannot be safely tested or risks breaking existing behavior.

Branching decision is based on operational risk:

If changes are safe to test directly and low risk, they are committed directly to main.
If changes are complex, multi-step, or potentially breaking, they are isolated in a feature branch before merge.

This keeps branch overhead minimal while preserving isolation where it is operationally necessary.

Active workflow pattern

feature branch → review/test → merge into main
small changes → direct commit to main

No long-lived branching models (e.g. GitFlow) are used.

Commit conventions

The repository follows a strict commit structure:

Format

Each commit uses:

Type prefix:
- feat – new functionality
- fix – bug fixes
- chore – non-feature changes (dependencies, refactors, maintenance)
- docs – documentation updates
- seo – SEO or marketing-related updates
Scope suffix:
- (fe) frontend changes
- (be) backend changes
- (fe/be) mixed changes

Examples

feat(fe): add guest checkout flow
fix(be): resolve coupon validation edge case
seo(fe): update homepage metadata

This structure is applied consistently across all repositories to maintain traceability between frontend/backend work and functional intent.

Branch usage overview

The image above reflects the current repository branch structure. It is intentionally simple and does not follow a complex branching model.

Working & contribution flow

Standard flow

Create branch only for multi-step or high-risk changes
Develop and test locally or on staging
Merge into main once stable

Direct-to-main flow

Used for:

small fixes
documentation updates
non-breaking UI adjustments
minor backend corrections

These are validated before push to ensure no runtime regression.

Repository state alignment

During initial stabilization, the live production system and repository history were not fully aligned due to legacy deployment practices.

A synchronization commit was introduced to align repository history with observed production behavior. This ensured consistency between deployed runtime and version control history going forward.

Staging environment

A staging branch exists and is used as an intermediate validation layer before production deployment where required. It is not part of a strict release/versioning system and does not use semantic version tags.

Deployment is functionally commit-driven rather than version-tag-driven.