Conventions & Standards

Écrire du code est une compétence. Collaborer avec des conventions est une pratique d’ingénierie.

Les conventions ne sont pas des règles arbitraires. Elles permettent à une équipe de :

Comprendre immédiatement l’historique d’un projet.
Maintenir la base de code plus facilement.
Automatiser le déploiement et la génération de changelogs.
Réduire les malentendus et accélérer la revue de code.

1. Conventions de Branches

Une branche doit être courte, explicite, prévisible et lisible.

Structure recommandée HashCode

type/description-courte

Exemple : feature/login ou fix/navbar.

Catégories de branches

Type	Rôle	Exemples
`feature/`	Nouvelle fonctionnalité	`feature/login`, `feature/payment`
`fix/`	Correction de bug standard	`fix/login-validation`, `fix/navbar-overflow`
`hotfix/`	Correction urgente directement en production	`hotfix/security-patch`, `hotfix/login-crash`
`release/`	Préparation d’une nouvelle version stable	`release/v1.0.0`, `release/v2.1.0`
`docs/`	Modification ou ajout de documentation	`docs/readme`, `docs/api-guide`
`refactor/`	Restructuration du code sans changement fonctionnel	`refactor/auth-service`, `refactor/db-helper`
`chore/`	Tâches de maintenance (dépendances, outils, CI)	`chore/update-deps`, `chore/setup-ci`

2. Conventions de Commits

Un commit de qualité doit répondre simplement à deux questions : Qu’est-ce qui a changé ? et Pourquoi ?.

Structure recommandée

Nous suivons le standard Conventional Commits :

type: description

Exemple : feat: add profile page

Règles de rédaction

Minuscules pour le type

Utilisez toujours des minuscules.

Correct : feat:
Incorrect : Feat: ou FEAT:

Description courte et précise

Soyez concis.

Correct : feat: add dashboard
Incorrect : feat: i added the dashboard page and some buttons

Utiliser l'impératif

Rédigez la description à l’impératif (en anglais de préférence, ou en français de façon homogène).

Correct : feat: add login page
Incorrect : feat: added login page ou feat: adding login page
Astuce : Le message doit compléter la phrase “This commit will…” (Ce commit va…)

Liste des types de commits

feat: : Nouvelle fonctionnalité (ex: feat: add notifications).
fix: : Correction de bug (ex: fix: resolve login validation).
docs: : Modifications de la documentation (ex: docs: update installation guide).
style: : Mise en forme du code (espaces, indentation, formatage) sans impact logique (ex: style: format auth service).
refactor: : Modification du code qui ne corrige pas un bug et n’ajoute pas de fonctionnalité (ex: refactor: simplify auth service).
test: : Ajout ou correction de tests (ex: test: add login unit tests).
chore: : Maintenance générale, configuration ou outils (ex: chore: update dependencies).
security: : Amélioration liée à la sécurité (ex: security: sanitize user inputs).
build: : Modifications affectant le système de build ou les dépendances externes (ex: build: configure docker image).
ci: : Changements dans les pipelines d’intégration continue (ex: ci: add github actions workflow).

3. Conventions de Pull Requests

Le titre de votre Pull Request doit décrire clairement le changement apporté (souvent en reprenant le format d’un commit conventionnel). La description doit donner tout le contexte nécessaire à vos pairs pour la revue de code.

Structure de description recommandée

## Summary
Ajout de la page de connexion.

## Changes
- Ajout du formulaire HTML de login.
- Ajout de la validation des inputs côté client.
- Gestion stylisée des messages d'erreur.
- Optimisation du responsive mobile.

## Testing
- Vérification du formulaire avec des identifiants valides/invalides.
- Test de rendu responsive sur simulateur mobile.

## Checklist
- [x] Les tests ont été exécutés localement.
- [x] La documentation a été mise à jour.
- [x] Aucun avertissement n'est généré dans la console.

4. Conventions d’Issues

Une issue doit être rédigée de manière à ce que n’importe quel développeur de l’équipe puisse la prendre en main et comprendre ce qu’il doit faire.

Structure recommandée

## Objective
Créer une page de connexion utilisateur sécurisée.

## Requirements
- Champ e-mail et champ mot de passe requis.
- Validation du format d'email côté client.
- Rendu responsive sur mobile et tablette.

## Acceptance Criteria
- L'utilisateur est redirigé vers le dashboard après connexion réussie.
- Un message d'erreur clair s'affiche si l'identifiant est incorrect.
- Le design respecte la charte graphique de la maquette.

5. Gestion de Versions (Semantic Versioning - SemVer)

Les versions de vos livrables ou paquets logiciels suivent la norme du versionnage sémantique sous la structure :

MAJOR.MINOR.PATCH

MAJOR (Majeur) : Introduit des changements d’API incompatibles (ex: refonte totale de l’architecture).
MINOR (Mineur) : Ajoute des fonctionnalités tout en restant rétrocompatible (ex: ajout du dashboard).
PATCH (Correctif) : Applique des corrections de bugs rétrocompatibles (ex: correction d’une erreur d’alignement).

6. Workflow professionnel HashCode

Le cycle complet de développement d’une modification logicielle suit le parcours ordonné ci-dessous :

flowchart TD
    Issue[1. Issue : Spécification du besoin]
    --> Branch[2. Branch : Création d'une branche isolée]
    --> Commit[3. Commit : Validation étape par étape avec convention]
    --> Push[4. Push : Publication sur le dépôt distant]
    --> PR[5. Pull Request : Demande d'intégration]
    --> Review[6. Review : Revue par les pairs et validation CI/CD]
    --> Merge[7. Merge : Intégration dans la branche principale]
    --> Release[8. Release : Livraison d'une nouvelle version SemVer]

    style Issue fill:#111827,stroke:#1F2937,color:#F9FAFB
    style Branch fill:#111827,stroke:#1F2937,color:#F9FAFB
    style Commit fill:#111827,stroke:#1F2937,color:#F9FAFB
    style Push fill:#111827,stroke:#1F2937,color:#F9FAFB
    style PR fill:#111827,stroke:#1F2937,color:#F9FAFB
    style Review fill:#111827,stroke:#1F2937,color:#F9FAFB
    style Merge fill:#111827,stroke:#1F2937,color:#F9FAFB
    style Release fill:#202A0A,stroke:#C5F441,stroke-width:2px,color:#F9FAFB