Branching Model
Purpose
Section titled “Purpose”The branch model must support continuous integration, scheduled release hardening, and traceable production code without long-lived divergence.
Nexa context
Section titled “Nexa context”Nexa currently has dev, test/release, and prod environments, but no per-feature preview environments. That constraint shapes the current bug-fix process.
Standard
Section titled “Standard”-
MUST: Use short-lived feature branches from
develop. -
MUST: Merge feature branches through reviewed PRs into
develop. -
MUST: Use
release/<version>branches cut from an exact develop commit at the release boundary. -
MUST: Use
mainas the internal production source of truth. -
MUST: Protect develop, release branches, and main from direct writes except approved automation.
-
MUST: Delete merged feature branches.
-
SHOULD: Keep release branches only for the supported release window.
-
SHOULD: Name branches predictably:
feature/,fix/,release/, andhotfix/.
Working model
Section titled “Working model”Normal development flows feature → develop → release → main. During the current release-hardening model, develop is frozen so fixes can be validated in Dev before being promoted to the release branch.
Evidence of compliance
Section titled “Evidence of compliance”Compliance is demonstrated through repository configuration, protected-branch settings, CI results, and review records. Teams should be able to show the evidence without reconstructing it manually.
Common failure modes
Section titled “Common failure modes”Long-lived feature branches, merging release back into develop without review, and using environment names as mutable dumping grounds cause divergence and hidden changes.
Maturity path
Section titled “Maturity path”The initial standard favors consistency and auditable automation. Exceptions and advanced controls are introduced only after the baseline is adopted across repositories.