Git Workflow & Branching Strategy

Branching Model:

• main: Always reflects production‑ready state.

• develop (optional): Integration branch for merged features before release.

• feature/*: New features or enhancements; branch off main or develop.

• bugfix/*: Critical fixes; branch off main or develop.

• release/*: Prepares code for a new production release; only bug fixes and documentation updates allowed.

• hotfix/*: Urgent fixes to production; branch off main and merged back into main and develop.

Naming Conventions:

• Feature branches: feature/short-summary (e.g., feature/order-book-pagination).

• Bugfix branches: bugfix/issue-number-description (e.g., bugfix/142-fix-null-pointer).

• Release branches: release/vX.Y.Z (e.g., release/v1.3.0).

• Hotfix branches: hotfix/vX.Y.Z-critical-bug.

Release Process:

1. Create release/vX.Y.Z from develop or main.

2. Update CHANGELOG.md with release notes.

3. Bump version in package.json and smart‑contract artifacts.

4. Merge release/vX.Y.Z into main and tag with vX.Y.Z.

5. Merge release/vX.Y.Z back into develop.

6. Deploy to staging and, after verification, promote to production.

Pull Request Workflow:

• All PRs must target the appropriate base branch.

• Use issue referencing (Closes #issue) to automate issue closure.

• Ensure PR passes CI (tests, lint, security scans) before merging.