Git & Quality Process

After work is planned and tracked in Trello, code and documentation changes move through Git. The team uses this branch structure:

main
 └── develop
      ├── feature/*
      ├── fix/*
      └── docs/*

• main — stable milestone and release code
• develop — shared integration branch
• feature/* — new functionality
• fix/* — bug fixes
• docs/* — documentation changes

New work begins from the latest version of develop:

git switch develop
git pull origin develop
git switch -c feature/allocation-board

Changes are submitted through Pull Requests and merged into develop after review. Stable milestone work is later merged from develop into main.

Commit Convention

Commit messages follow Conventional Commits.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Examples include:

feat: add allocation validation
fix(login-redirect): correct login redirect
docs: add project roadmap
test: add allocation endpoint tests
refactor: simplify allocation service
chore: update dependencies
ci: update deployment workflow

Commit messages should describe the actual change and should avoid vague messages such as update, changes, done, or final.

Quality Checks

Before work is committed and pushed, contributors should run the quality checks configured for the relevant repository.

Lint -> Tests -> Build / Validation -> Review -> Commit -> Push

Only checks actually configured in the relevant repository are required.

The team's dedicated runner setup and reliability improvements are described in CI/CD Runner Infrastructure.

For the documentation repository, the validation command is:

python -m mkdocs build --strict

Definition of Done

A task is considered complete when:

• implementation or documentation is finished;
• relevant tests or validation checks pass;
• the work has been reviewed;
• no sensitive credentials have been committed;
• required documentation has been updated;
• changes are merged into develop; and
• the Trello card has been moved to Done.