47 lines
1.7 KiB
Markdown
47 lines
1.7 KiB
Markdown
Contributing Workflow
|
|
=====================
|
|
|
|
Use this guidance when you spin up a new project from the template or accept contributions from collaborators.
|
|
|
|
Branching model
|
|
---------------
|
|
- Work from short-lived topic branches cut from `main`.
|
|
- Prefix branches with the work type: `feat/`, `fix/`, `docs/`, `chore/`, `refactor/`, `test/`.
|
|
- Keep branch names descriptive but short (e.g. `feat/billing-invoices`, `fix/auth-timeout`).
|
|
|
|
Commit messages
|
|
---------------
|
|
Follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
|
|
```
|
|
<type>(<scope>): <subject>
|
|
```
|
|
Examples:
|
|
- `feat(api): add artist listing endpoint`
|
|
- `fix(infra): handle wrangler env missing`
|
|
- `docs(adr): record storage strategy`
|
|
|
|
Pull request checklist
|
|
----------------------
|
|
1. Rebase onto `main` before opening the PR.
|
|
2. Fill out `.gitea/pull_request_template.md` so reviewers know how to test.
|
|
3. Ensure automated checks pass locally:
|
|
```bash
|
|
pnpm install
|
|
pnpm lint
|
|
pnpm test
|
|
pnpm build
|
|
```
|
|
Adjust the commands if your project uses a different toolchain.
|
|
4. Link issues with `Fixes #id` or `Refs #id` as appropriate.
|
|
5. Squash-merge once approved to keep history clean (use the Conventional Commit format for the squash message).
|
|
|
|
Quality expectations
|
|
--------------------
|
|
- Keep docs current. Update the README, edge-case catalogue, or stack decisions when behaviour changes.
|
|
- Add or update tests alongside your changes—tests are treated as executable documentation.
|
|
- Avoid committing secrets or large binaries; rely on `.env` files, secret managers, or storage buckets instead.
|
|
|
|
Questions?
|
|
----------
|
|
Open an issue or start a draft PR and document what you are unsure about. Future readers will thank you for the breadcrumbs.
|