This document outlines the workflow and coding standards for our group project. Please follow these guidelines to ensure a smooth collaboration and high code quality.
We follow a Feature Branching workflow.
main: Always stable. Only contains finished, peer-reviewed milestones.development: The integration branch where all features are merged before going to main.feature: New functionality (e.g.,feature/game-logic,feature/socket-setup).misc: (e.g.,fix/card-rendering).
- Take on a ticket.
- Pull the latest changes from
development. - Create a new branch:
git switch -c feature/your-feature-name. - Commit your changes using Conventional Commits (see below).
- Ensure your branch is up to date with current codebase.
- Push your branch and open a Pull Request (PR) to
development. - Ensure PR only contains changes relevant to the ticket.
- If multiple changes are to be made, a new branch should be created.
To keep the history readable, use the following format:
<type>(<scope>): <short summary>
feature: A new featurefix: A bug fixdocs: Documentation only changesrefactor: Code changes that neither fix a bug nor add a feature- There are other types of commits that can be made, but they have to be tagged accordingly.
- DRY Principle: Do not repeat code. Extract or reuse if logic has already been implemented.
- Language: All code, comments, and documentation must be in English.
- Google Code Style: All PRs (Backend) must fulfill Google Code Style standards.
- ktlint: All PRs (Frontend) must have been linted by ktlint (command in README.md).
- No rebase or squash merges
- Java Docs as enforced by Google Code Style.
PRs must be made into development and not into main
- Self-Review: Check your code for print statements or debug logs before submitting.
- Reviewer: At least two other team members must approve the PR.
- Discussion: Use PR comments to discuss architectural choices.
- 80% Code coverage as per SonarQube.
- Fix issues raised by SonarQube.