Documenter les conventions dans le dépôt

Quand plusieurs personnes contribuent au même dépôt, des règles seulement connues oralement finissent par être appliquées de façon inégale. Une personne peut créer une branche au nom ambigu, ou envoyer un commit dont le message ne permet pas d’identifier le changement. Vous allez consigner les conventions retenues dans README.md et les formuler de manière à pouvoir vérifier leur application.

README.md est le point d’entrée documentaire du dépôt. Il doit permettre à une personne qui arrive sur le projet de comprendre comment contribuer, sans remplacer les détails de chaque proposition de changement. Dans cette leçon, vous ajoutez une section de contribution à ce fichier ; vous ne modifiez ni index.html, ni style.css, ni .gitignore.

Les décisions de flux sont déjà prises : l’équipe utilise des branches de fonctionnalité courtes et rebase la branche de travail avant une intégration par avance rapide. Comme vous l’avez vu dans les deux leçons précédentes, la branche principale est protégée et l’historique doit rester linéaire. Ici, l’objectif est de rendre ces décisions accessibles et concrètes, pas de redéfinir la stratégie.

Une consigne utile indique une action, un format attendu et, si nécessaire, un exemple. Par exemple, « nommez les branches clairement » laisse place à plusieurs interprétations ; « utilisez feature/ pour une évolution et fix/ pour une correction, suivis de quelques mots en minuscules séparés par des tirets » donne un critère contrôlable. Les préfixes sont des conventions d’équipe : ils ne modifient pas le comportement de Git.

Le format des messages de commit doit aussi aider à comprendre l’historique. Vous pouvez demander une première ligne concise, rédigée à l’impératif, qui décrit un seul changement. Évitez les messages tels que « divers », « corrections » ou « travail », qui ne permettent pas de retrouver l’intention sans examiner immédiatement chaque fichier.

Le bloc suivant constitue un contenu autonome pour la section de contribution du dépôt. Si votre README.md contient déjà une présentation du site, conservez-la et ajoutez cette section à la suite ; ne remplacez pas des informations existantes pertinentes. Les exemples utilisent les préfixes définis ici et décrivent la procédure retenue pour le projet.

# Structurer le dépôt d’un site devenu produit

## Contribuer

Les changements du site sont proposés sur des branches courtes, puis intégrés à `main` après revue. Ne poussez pas directement sur `main` et ne réécrivez pas son historique.

### Nommer une branche

Créez une branche distincte pour chaque changement. Utilisez l’un de ces préfixes, suivis d’une description courte en minuscules, avec des tirets entre les mots :

- `feature/` pour une évolution, par exemple `feature/page-contact` ;
- `fix/` pour une correction, par exemple `fix/lien-navigation` ;
- `docs/` pour une modification de documentation, par exemple `docs/regles-contribution`.

Évitez les noms génériques comme `test`, `modifs` ou `travail`.

### Rédiger un message de commit

Rédigez la première ligne à l’impératif, avec une majuscule initiale, sans point final et en décrivant un seul changement. Exemples :

- `Ajoute la page de contact`
- `Corrige le lien vers la navigation`
- `Documente les règles de contribution`

Un message comme `Mise à jour` ou `Divers` ne décrit pas suffisamment le changement.

### Mettre à jour et proposer un changement

Avant de proposer l’intégration, rebasez votre branche sur la version actuelle de `main` et résolvez les conflits sur votre branche de travail. Vérifiez les changements, puis ouvrez une proposition de fusion en décrivant son objectif et les contrôles effectués. Demandez une revue à une personne qui n’a pas réalisé le changement.

L’intégration se fait par avance rapide afin de conserver un historique linéaire. La branche `main` est protégée : les changements doivent passer par la revue et les contrôles requis. Les mises à jour directes et forcées de `main` sont interdites.

### Vérifier avant la revue

- Confirmez que les fichiers modifiés correspondent au périmètre annoncé.
- Exécutez les contrôles applicables et indiquez leur résultat dans la proposition.
- Vérifiez que les noms de branche et les messages de commit suivent les conventions ci-dessus.
- N’ajoutez aucun secret, jeton ou identifiant sensible au dépôt.

Si une convention doit changer, proposez la modification de cette section pour revue par l’équipe avant de l’appliquer aux contributions suivantes.

Une fois le texte ajouté, relisez-le en vous plaçant dans la situation d’une personne qui prépare une contribution. Elle doit pouvoir choisir un nom de branche, rédiger un message conforme et comprendre le parcours jusqu’à l’intégration. Les exemples constituent des tests simples de la documentation : feature/page-contact suit la règle de nommage, tandis que travail ne la suit pas.

Vous pouvez aussi vérifier le changement documentaire avant de le proposer :

git diff --check
git diff -- README.md
git status --short

git diff --check ne signale pas d’erreur d’espacement. git diff affiche la modification de README.md ; git status --short permet de confirmer que seuls les fichiers attendus sont modifiés.

Ces commandes ne prouvent pas que toutes les règles seront respectées automatiquement ; elles permettent de relire le contenu et de détecter des erreurs élémentaires dans le changement. Les contrôles automatiques avant fusion seront définis dans une partie ultérieure du cours. Pour l’instant, la revue vérifie que la documentation correspond bien aux décisions d’équipe déjà prises.

• Placez les consignes de contribution dans README.md, point d’entrée documentaire du dépôt.
• Définissez des conventions explicites pour les noms de branches et les messages de commit, avec des exemples conformes.
• Documentez le parcours de contribution cohérent avec les décisions précédentes : rebase, revue et intégration par avance rapide sur main protégée.
• Relisez le diff et vérifiez que le texte est applicable, sans annoncer comme automatiques des contrôles qui ne sont pas encore configurés.

Dans la prochaine leçon, vous apprendrez à transformer un défaut en test reproductible avant de rechercher le commit qui l’a introduit.