| name | git-workflow |
| description | Commit message format, branch naming, and the pull request workflow for this project. Use when the user asks to commit, name a branch, or prepare changes for review. |
Git Workflow
1. Commit Messages
Write the subject as a plain capitalized sentence in the imperative mood, with no type
prefix:
Add caching to profile lookup
[Optional body — wrap at 72 characters. Explain *what* and *why*, not *how*.
A bulleted list is fine for a change that touches several areas.]
[Optional footer — e.g., Closes #123, Co-authored-by: Name <email>]
Rules
- Subject line MUST be imperative mood ("Add X", not "Added X" or "Adds X").
- Subject line MUST be capitalized and MUST NOT end with a period.
- Do NOT prefix the subject with a Conventional Commits type such as
feat: or fix:.
This project does not use them.
- Keep the subject under 72 characters, including the
(#N) that a squash merge appends.
- Separate subject from body with a blank line.
- Body lines MUST NOT exceed 72 characters.
- Reference related issues in the footer.
- Each commit MUST represent one logical change. Do NOT mix unrelated changes.
When a pull request is squash-merged, GitHub appends its number to the subject, producing
history entries such as Increase test coverage, improve docstrings, minor bug fixes (#13).
Do not add the (#N) yourself.
2. Branching Strategy
main — Always releasable. Protected; requires PR review and passing CI. Releases
are created by tagging commits on main.- Work branches — Named
<initials>_<YYMMDD>_<topic>, for example rf_251204_mixins
or rf_250712. A short descriptive name such as mark-reorg is also acceptable for
one-off work.
Branch from main. Do NOT use feature/ or bugfix/ prefixes, and do NOT create
separate release, hotfix, or develop branches. All work merges back to main via pull
request.
3. Pull Requests and Merging
- ALWAYS create a PR for merging into
main; direct pushes are prohibited.
- PRs MUST pass all CI checks (lint, type-check, tests) before merge.
- Prefer squash merge to keep
main history linear and readable.
- Delete the source branch after merge.
4. Tagging and Releases
- Tag releases on
main with semantic versioning: v<MAJOR>.<MINOR>.<PATCH>.
- Let
setuptools_scm derive the package version from tags automatically.
- Creating a GitHub Release from the tag triggers the PyPI publish workflow.
