git-flowlisted

## When to use Reach for this when you start a feature branch, open a merge request, promote code between environments, tag a release, or ship an urgent production fix. It is the **branching & release** workflow; for commit-message rules and the "never target main for feature work" guard see the global *Git Commit Rules* / *Branch & PR Target Rules* in `CLAUDE.md`. > Branch **names** vary by project — some teams use `staging`, others `RC`, for the pre-production > branch. What matters is the **role** each branch plays, not its literal name. Map the names below > to your project's. This is plain git, so it applies to a repo in any language. ## Branch roles | Branch | Role | |---|---| | `master` (or `main`) | Production. Only thoroughly tested code. Tagged per production release. | | `staging` (or `RC`) *(optional)* | Pre-production / demo. Tagged per staging release. Optional if you have strong feature flags. | | `develop` | Integration branch for active development; deploys to the Dev environment. | | `feature/*` | One per task/feature. Branches from `develop`. | | `hotfix/*` | Critical production-bug fixes. Branches from `master`. | ## Steps ### 1. Feature development ```bash git checkout develop git pull origin develop git checkout -b feature/your-feature-name # always branch from fresh develop # ...commit focused work... ``` Open a merge request **into `develop`**. After review, merge (`--no-ff`) — this triggers the Dev deployment. Keep one feature branch to on