Thank you for your interest in contributing to Meet@Mensa! This document provides guidelines for commit messages and branch naming conventions to maintain a clean and consistent git history.
We follow the Conventional Commits specification for our commit messages. This helps maintain a clean and consistent git history and enables automated versioning and changelog generation.
Each commit message consists of a header and an optional body:
<type>(<scope>): <description>
[optional body]
feat: A new featurefix: A bug fixdocs: Documentation only changesstyle: Changes that do not affect the meaning of the code (white-space, formatting, etc)refactor: A code change that neither fixes a bug nor adds a featureperf: A code change that improves performancetest: Adding missing tests or correcting existing testschore: Changes to the build process or auxiliary tools and libraries
The scope is optional. If used, it should be the name of the module affected (e.g., user, matching, ui).
The description should be in the imperative mood and should not be capitalized. It should not end with a period.
feat: display invitations on landing page
fix: remove incorrect API request
feat(auth): add email verification
fix(matching): resolve incorrect group size calculation
docs(readme): update installation instructions
We use a structured approach to branch naming that helps identify the purpose and scope of changes.
<type>/<short-description>
feature: New features or enhancementsbugfix: Bug fixeshotfix: Urgent fixes for production issuesrelease: Release preparationdocs: Documentation updatesrefactor: Code refactoringtest: Adding or updating tests
feature/add-lunch-invitations
bugfix/fix-matching-algorithm
docs/update-api-documentation
- Use hyphens to separate words in the description
- Keep descriptions concise but descriptive
- Use lowercase letters
- Avoid special characters
- Link related issues in the pull request description
- Create a new branch for each feature or bugfix
- Follow the commit message guidelines for all commits
- Create a pull request that uses our PR template
- Include a clear description of changes
- Reference any related issues or tickets in the PR description
- Ensure all tests pass before submitting