Branches and pull requests

Which branch to start from, how releases happen, and how fixes flow back.

In one line: branch from dev, PR back into it; a release is dev merged into main and a version tag; nobody pushes to a protected branch.

Branch	What happens	Gets code from
your feature branch	your machine only	branched from `dev`
`dev`	collects features for the next release	PR from a feature branch
`main`	what was released; a `vX.Y.Z` tag on it makes the release (Releases)	PR from `dev`

The msaving monorepo and msaving-landing use these branches (merging landing’s main deploys the website). Nothing deploys an app: operators build releases from their own checkout.

Special cases

Urgent fix to a release: branch from main, PR into main, tag a PATCH release, then merge main back into dev.

Rules

dev and main are protected: pull request with passing checks only, no force pushes.
Never push tags from a laptop: the release workflow makes them.
Only maintainers merge into main and tag releases.

Branch names and commits

feat/..., fix/..., docs/..., chore/.... Commit messages are a short plain sentence of what changed (“Dashboard: return every category with spending this month”).

A good pull request

One concern per PR. In the monorepo, a change that spans backend and web can be one PR; see Changes across repos.
Checks pass locally first (Run the tests).
Migrations and tests change together. If it changes documented behaviour (a route, a setting, an error code, a setup step), the docs (src/content/docs/ in msaving-landing) change in a paired PR.
Says what you tested and how (for UI: the steps you clicked through).
If it changes setup, settings, backups or commands, the README changes in the same PR.
If it makes a page on this site wrong, it fixes that page too (or a PR here follows right after).