Skip to main content

​
Git & Release Workflow

​
Commit Messages

IMPORTANT: This project uses commitlint. Commits that don’t follow the format will be rejected by the pre-commit hook.

​
Format

  • Subject line: type(scope): description or type: description
  • Types allowed: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test
  • Line length: Body lines must NOT exceed 100 characters
  • Scope: Optional, e.g. feat(auth): add login page

​
Examples

feat(tables): add sorting support
fix: resolve pagination bug in CoreTable
docs: update getting-started guide

​
Releases

IMPORTANT: Never create a release without explicit user consent. Releases are irreversible and affect all downstream projects.

​
When Asked to Make a Release

Note: If the user asks to “commit and make a release”, they likely mean “commit, push, and then release”. Ask for clarification to confirm they want to push changes before triggering the release. Read the docs/releases.md file for the complete release process. Key steps:
  1. Ensure all desired changes are committed and pushed
  2. Ask about updating UPGRADE.md
  3. Confirm with the user before proceeding
  4. Use bin/release.sh with --dry-run first, then execute the release