| Branch | Purpose |
|---|---|
main |
Main branch, stable |
dev |
Development branch |
feature/[issue/discussion-id]-xxx-xxx
improvement/[issue/discussion-id]-xxx-xxx
bugfix/[issue/discussion-id]-xxx-xxx
feature— New featuresimprovement— Improvements and optimizationsbugfix— Bug fixes[issue/discussion-id]— Linked Issue or Discussion ID, e.g.#42xxx-xxx— Short description, separated by hyphens
Examples:
feature/#42-add-proxy-provider
improvement/#15-refactor-config-parser
bugfix/#8-fix-dns-leak
Follow the Conventional Commits specification:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
| type | Description |
|---|---|
feat |
New feature |
fix |
Bug fix |
improve |
Improvement |
refactor |
Code refactoring |
perf |
Performance optimization |
docs |
Documentation |
chore |
Build/tooling/dependencies |
test |
Testing |
ci |
CI/CD |
Examples:
feat: add proxy provider support
fix(config): correct DNS rule parsing
improve(ui): optimize connection list rendering
- For breaking changes, add
BREAKING CHANGE:in the footer. - Reference related issues in the body:
Closes #42orRefs #15.
A CHANGELOG.md is maintained at the project root, following the Keep a Changelog format.
Update the CHANGELOG when releasing a new version. Before tagging a release, summarize changes since the last release into CHANGELOG.md, grouped as follows:
| Group | Description |
|---|---|
Added |
New features |
Changed |
Changes in functionality |
Deprecated |
Soon-to-be removed |
Removed |
Removed features |
Fixed |
Bug fixes |
Security |
Security fixes |
Do not modify CHANGELOG in daily commits — only update it at release time. Since commit messages follow Conventional Commits, tools like git-cliff can auto-generate the changelog.
Run once after clone:
git config core.hooksPath .githooks