Commit Conventions

Parcelis uses Conventional Commits to make the project history readable and release automation possible.

Write commit subjects in this form:

type(optional-scope): short imperative description

Use one of these lowercase types:

• feat: a new user-facing capability.
• fix: a bug correction.
• docs: documentation-only changes.
• refactor: code restructuring without changing behavior.
• test: test additions or corrections.
• perf: a performance improvement.
• build: build system or dependency changes.
• ci: continuous-integration changes.
• chore: maintenance that does not fit another type.
• revert: reverses an earlier change.

Scopes are optional. Use a concise monorepo area when it helps, such as web, api, db, ui, docs, or infra.

feat(web): add property filters
fix(api): reject duplicate unit names
docs: explain production deployment

Use ! before the colon or a BREAKING CHANGE: footer for a breaking change.

feat(api)!: rename the properties endpoint

Pull requests validate every commit message in CI. When squash merging, use a Conventional Commit for the pull-request title because it becomes the final commit message.

Pull requests also run the Gitleaks secret scan. Fork and Dependabot PRs use the CLI without organization secrets. Revoke or rotate real credentials immediately; removing them in a later commit does not undo exposure. See secret scanning for local scanning, false-positive review, and maintainer setup.

Open the Gitleaks check's Details and expand the failed scan step to inspect its findings or setup error. Same-repository PRs also receive review comments for detected secrets; fork and Dependabot PRs show findings in redacted logs.

For the complete contributor policy, see the repository's CONTRIBUTING.md.