Contribution Guidelines - bounswe/bounswe2025group5 GitHub Wiki
As a team of 10 contributors working on this project, having a common set of Git guidelines helps us stay organized and consistent. Following the same structure for commits and pull requests makes it much easier to trace contributions, understand changes, and collaborate efficiently. These shared practices ensure that everyone’s work integrates smoothly and the project history remains clear and maintainable over time.
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.
To keep our project clean, traceable, and easy to maintain, we follow Conventional Commits and structured Pull Request workflows.
<type>(optional scope): <short summary>
feat(backend): add email verification for signup
We need to specify the type of the commit to indicate what kind of work we done:
| Type | Purpose |
|---|---|
| feat | A new feature or enhancement |
| fix | A bug fix |
| docs | Documentation changes only |
| refactor | Code restructuring without behavior change |
| test | Adding or updating tests |
| chore | Maintenance tasks (build, CI, deps, etc.) |
You can add a scope in parentheses to specify which part of the codebase is affected:
feat(mobile): fix(frontend): docs(devops):
- Use imperative mood: “add”, not “added” or “adds”.
- Keep the subject under 72 characters.
- If you need a longer explanation, add a blank line before the description:
feat(backend): implement new task scheduling system
This change introduces a new scheduling mechanism that improves job prioritization
and reduces latency under load.
Use descriptive branch names to indicate purpose and type, and do not forget to delete the branch after a successful merge.
| Type | Format | Example |
|---|---|---|
| Feature | feature/short-description | feature/add-user-profile |
| Bug fix | fix/short-description | fix/login-redirect |
| Documentation | docs/short-description | docs/api-guide |
| Refactor | refactor/short-description | refactor/job-service |
Avoid genering names like patch, update or temp
- The develop branch will merge to the main branch periodically with being sure about everything works as expected in develop.
- The features branches will be opened from develop for all of the teams.
Follow these steps to open a clean and reviewable PR.
git checkout -b feature/add-dashboardUse conventional commit messages
git add .
git commit -m "feat(frontend): add challenge visualization page"git push origin feature/add-dashboardOn GitHub:
- Open your branch and click “Compare & pull request”.
- Use a clear PR title, matching the main commit:
feat(frontend): add challenge visualization page - In the PR description:
- Explain what you changed and why.
- Reference related issues (e.g., Closes #42).
