karolinakita-ux/portfolio

Publier une modification sur develop

Chaque commit est une version. Règles dans CONTRIBUTING.md ("Chaque commit") ; la forme courte :

1. Vérifier. yarn verify (vérification de types, lint sans avertissements, vérification Prettier, tests, build avec pré-rendu). Corriger le code, pas les règles : une exception à une règle est une désactivation d'une ligne avec une raison après --.
2. Vérifier l'arbre. git status. L'utilisateur peut avoir des modifications non terminées : lister uniquement les fichiers que cette modification a touchés. Laisser tout le reste non indexé.
3. Choisir la version juste avant de commiter (lire version dans package.json et le haut de CHANGELOG.md maintenant, pas avant) :
   • majeure : pages supprimées ou renommées, URLs modifiées, une refonte
   • mineure : nouveau contenu visible ou fonctionnalités
   • correctif : corrections, copie, images, style, dépendances, configuration, tests, documentation
4. Changelog. Ajouter ### X.Y.Z - AAAA-MM-JJ sous le seul en-tête ## Unreleased (après une publication, il a disparu : l'ajouter au-dessus de la ## Release la plus récente), avec les groupes Added / Changed / Fixed / Removed, une ligne simple chacun, uniquement des tirets courts.
5. Commiter les fichiers listés par leur nom : git commit -- <fichiers> avec le sujet <ce qui a changé, impératif> (X.Y.Z), un corps court, et le cartouche co-auteur si Claude l'a écrit.
6. Vérifier le commit par rapport à son message : git show --stat HEAD. Puis pousser develop.

Avant de commiter, lister chaque unité modifiée (fichier, fonction, branche) à côté du test qui la couvre. Une branche non testée reçoit un test, ou une note dans la réponse.