Git Workflow

Proxima Console uses trunk-based development with short-lived feature branches.

Branching Strategy

• main is protected and must always be deployable.
• Feature branches are short-lived (1--3 days) and merge back into main via merge requests.
• There are no develop, staging, or release branches.
• All merges happen through merge requests only. The CI pipeline must pass before merging.

Branch Naming

Use one of the following patterns:

MNG-123              # Jira ticket reference
feat/description     # Feature branch
fix/description      # Bug fix branch

Branch Protection

The main branch has the following protections:

• Allowed to merge: Maintainers only
• Allowed to push: No one (all changes go through merge requests)
• Required: Merge request approval and passing CI pipeline

Commit Messages

All commits follow the Conventional Commits specification:

<type>(<scope>): <description> [MNG-XXX]

Types

Type	Purpose
feat	New feature
fix	Bug fix
docs	Documentation changes
refactor	Code refactoring (no behavior change)
test	Adding or updating tests
chore	Maintenance tasks
perf	Performance improvements
style	Code style changes (formatting, whitespace)
ci	CI/CD pipeline changes

Scopes

Scope	Area
agent	Agent service (Go)
backend	Backend service (Go)
frontend	Frontend application (React/TS)
db	Database migrations and schema
nats	NATS messaging
mcp	MCP server
infra	Infrastructure and deployment

Examples

feat(agent): add host inventory collection [MNG-101]
fix(backend): handle nil pointer in host lookup [MNG-205]
test(frontend): add unit tests for HostDetail component
docs: update API reference for environments endpoint
ci: add container scanning with Trivy

Releases

Releases use semantic versioning via git tags:

• Stable releases: v0.1.0, v0.2.0, v1.0.0
• Pre-releases: v0.1.0-rc.1, v0.2.0-beta.1

The CI pipeline automatically builds and publishes artifacts when a tag is pushed.