Source document:
docs/commit-regulations.md
Goal
The project’s commit regulations exist to keep the history consistent, understandable, and maintainable.
Commit message structure
The upstream guide recommends the following layout:
<type>(<scope>): <subject>
<body>
<footer>
Common types
feat— new featureupd— update to an existing featurefix— bug fixdocs— documentation changestyle— formatting or style-only changerefactor— internal restructuring without feature changechore— maintenance or dependency worktest— test additions or updatesci— continuous integration changes
Subject-line guidance
- use the imperative mood
- keep it concise and descriptive
- avoid vague messages such as “Fix stuff”
- prefer lowercase unless a proper noun requires otherwise
Commit size and frequency
The project prefers commits that are:
- small and focused
- atomic, so they can be reviewed or reverted independently
- frequent enough to show progress without flooding the history with trivial noise
Additional practices
- write meaningful commit messages
- rebase before merging when appropriate
- squash overly fragmented work before landing on the main branch