Aller au contenu

Contribuer à Primatch

Ce guide explique les conventions à respecter pour contribuer au projet.

Flux de travail Git

# 1. Partir d'une branche à jour
git checkout main && git pull

# 2. Créer une branche feature
git checkout -b feat/game-score-validation

# 3. Développer et committer régulièrement
git add -p                    # Staging sélectif (jamais git add .)
git commit -m "feat(match): add score validation rules"

# 4. Push et ouvrir une PR
git push origin feat/match-score-validation

Convention de nommage des branches

feat/[domaine]-[courte-description]      # Nouvelle fonctionnalité
fix/[domaine]-[courte-description]       # Correction de bug
refactor/[domaine]-[courte-description]  # Refactoring
docs/[section]-[courte-description]      # Documentation uniquement
test/[domaine]-[courte-description]      # Ajout de tests

Convention de commits (Conventional Commits)

<type>(<scope>): <description>

Types : feat, fix, refactor, test, docs, chore, ci
Scopes : auth, game, club, frontend, docs, docker

Exemples :
  feat(game): add score validation with padel rules
  fix(auth): handle expired refresh token edge case
  test(game): add e2e test for score submission flow
  docs(fonctionnel): add game use cases

Checklist avant de soumettre une PR

  • Tests unitaires écrits et passants (make test)
  • Tests frontend écrits et passants (make test-frontend)
  • Couverture ≥ 80% (make test-coverage)
  • PHPStan niveau 6 sans erreur (make phpstan)
  • TypeScript sans erreur (make typecheck)
  • Lint propre (make lint)
  • Documentation mise à jour (règles métier si nouveau comportement, API si nouvel endpoint)
  • mkdocs.yml mis à jour si nouvelle page de doc
  • Swagger régénéré si endpoint modifié (make swagger-generate)

Revue de code

Ce qu'on vérifie

Ce qu'on ne critique pas

  • Style personnel (Pint/ESLint s'en chargent)
  • Nit-picks non bloquants (commenter mais pas bloquer la PR)