Préparer les conventions du dépôt

Quand un site statique devient un produit, les changements ne se limitent plus à modifier une page : plusieurs personnes contribuent, les mises en ligne doivent rester fiables et les corrections doivent être traçables. Sans règles écrites et vérifiables, chaque proposition de fusion devient une négociation différente. Vous allez préparer les conventions du dépôt et les relier aux contrôles déjà définis.

Partir des changements réels du dépôt

La cartographie des changements et des responsabilités, étudiée dans la leçon correspondante, vous fournit déjà les catégories et les personnes à consulter. Pour écrire des conventions utiles, transformez ces catégories en décisions opérationnelles : quel nom donner à la branche, qui relit la modification et quel contrôle doit réussir avant la fusion ? Une règle est exploitable si un contributeur peut l’appliquer sans deviner l’intention de l’équipe.

Cette matrice ne remplace pas la répartition des responsabilités : elle indique les décisions que la documentation doit rendre visibles. Pour le dépôt du site, adoptez des branches courtes de fonctionnalité, avec un nom lisible tel que feature/navigation-guide ou fix/lien-interne. Les changements destinés à la branche principale passent par une proposition de fusion, une revue et les contrôles automatisés requis ; la mise à jour de la branche de travail se fait par rebase, conformément à l’historique linéaire retenu précédemment.

Rédiger des consignes applicables

Ajoutez à README.md les règles que les personnes doivent connaître avant de contribuer. Décrivez le format des noms de branches, la forme des messages de commit, les éléments attendus dans une proposition de fusion et les conditions d’intégration. Restez cohérents avec la configuration du service Git : ne demandez pas une méthode de fusion que la branche protégée interdit.

# Contribuer au dépôt

## Stratégie de branches
- Créez une branche courte depuis `main` pour chaque changement.
- Utilisez `feature/` pour une évolution et `fix/` pour une correction.
- Rebasez votre branche sur `main` avant de demander la fusion.
- Intégrez les changements par avance rapide afin de conserver un historique linéaire.

## Commits
Utilisez le format `type: description`, par exemple `docs: préciser les contrôles avant fusion`.
Gardez chaque commit centré sur un objectif cohérent.

## Revue et proposition de fusion
- Décrivez le besoin, les fichiers modifiés et les vérifications effectuées.
- Demandez une revue à une personne compétente pour le périmètre concerné.
- Répondez aux commentaires, puis relancez les contrôles après toute modification.
- Fusionnez uniquement quand les approbations et les contrôles requis sont au vert.

## Contrôles et fichiers sensibles
Vérifiez les liens internes et la génération du site avant la fusion. Ne versionnez aucun secret ; les exclusions de `.gitignore` ne retirent pas un fichier déjà suivi de l’historique.

Cet exemple est une proposition de contenu pour README.md, pas une nouvelle structure de fichier ni une modification de la page HTML. Ajustez les termes à ceux utilisés par votre équipe, puis confrontez chaque règle à la configuration existante. En particulier, conservez le nom de la branche principale effectivement utilisé par le dépôt ; si elle ne s’appelle pas main, remplacez cet exemple dans la documentation.

Vérifier la contribution de bout en bout

Un exemple conforme permet de vérifier que les consignes sont assez précises. Pour une correction d’un lien dans index.html, le contributeur crée une branche fix/lien-interne, rédige un commit comme fix: corriger le lien vers la section contrôles, explique le défaut dans sa proposition et indique que les tests de liens et la génération du site ont réussi. Une personne relit le changement, les contrôles requis passent après les dernières modifications, puis la branche est intégrée selon la règle linéaire.

• Chaque catégorie de changement du site mène à des consignes concrètes, sans inventer de responsabilités nouvelles.
• Les exemples de branches et de commits peuvent être appliqués sans ambiguïté.
• La revue, les contrôles requis et la méthode d’intégration concordent avec les paramètres de protection.
• Les règles de sécurité rappellent qu’un fichier ignoré peut rester suivi et qu’aucun secret ne doit être versionné.
• Un nouveau contributeur peut décrire les vérifications attendues avant de demander une fusion.

Faites relire README.md par des personnes qui contribuent au contenu, à la présentation et à la configuration du dépôt. Si une consigne ne peut pas être reliée à un contrôle, à une étape de revue ou à une règle de branche, clarifiez-la ou retirez-la. Vous pouvez ensuite tester les conventions sur une contribution fictive et noter les questions qui restent sans réponse, sans encore simuler une régression ni un incident de récupération.

À retenir

• Reliez les catégories de changements à des consignes de branche, de revue et de contrôle.
• Documentez dans README.md le flux réellement appliqué au dépôt.
• Vérifiez la conformité des exemples avec la protection de la branche principale et l’historique linéaire.
• Évaluez les conventions en demandant si un contributeur peut les appliquer et si l’équipe peut les vérifier.

Dans la prochaine leçon, vous simulerez une régression sur une page du projet et consignerez les résultats de la recherche.