This project uses Conventional Commits and Semantic Versioning.
Each commit message consists of a header, a body (optional), and a footer (optional).
<type>(<scope>): <subject>
<body>
<footer>
- feat: A new feature (minor version bump)
- fix: A bug fix (patch version bump)
- docs: Documentation only changes
- style: Changes that don't affect code meaning (formatting, missing semicolons, etc.)
- refactor: Code change that neither fixes a bug nor adds a feature
- perf: Performance improvement
- test: Adding missing tests or correcting existing tests
- chore: Changes to build process, auxiliary tools, or maintenance tasks
- ci: CI configuration changes
- build: Build system or external dependency changes
The scope could be:
docker: Docker configuration changeswordpress: WordPress-specific changeslaravel: Laravel-specific changestraefik: Traefik configurationscripts: Shell scripts or automationdocs: Documentation
# Feature with scope
feat(docker): add Redis service for Laravel caching
# Bug fix
fix: resolve MySQL connection timeout in docker-compose
# Breaking change (major version bump)
feat(docker)!: upgrade to PHP 8.3
BREAKING CHANGE: PHP 8.3 requires updating all WordPress plugins
# Documentation
docs: update README with new environment variables
# Chore
chore: update npm dependenciesFor an interactive commit experience:
npm run commitThis will guide you through creating a properly formatted commit message.
-
Create a feature branch
git checkout -b feature/your-feature-name
-
Make your changes
- Follow existing code patterns
- Update documentation if needed
- Test your changes
-
Commit using conventional commits
npm run commit # or git commit -m "feat(docker): add new service"
-
Push and create a Pull Request
git push origin feature/your-feature-name
-
Automated Release
- When PR is merged to
main, semantic-release automatically:- Analyzes commits
- Determines version bump
- Updates CHANGELOG.md
- Creates GitHub release
- Tags the release
- When PR is merged to
fix:commits → Patch release (1.0.0 → 1.0.1)feat:commits → Minor release (1.0.0 → 1.1.0)BREAKING CHANGE:in footer → Major release (1.0.0 → 2.0.0)!after type → Major release (1.0.0 → 2.0.0)
developbranch: Creates pre-release versions (e.g., 1.1.0-develop.1)betabranch: Creates beta versions (e.g., 1.1.0-beta.1)mainbranch: Creates stable releases