Gerrit/Commit message guidelines/fr

Le message de validation (commit) de vos modifications joue un rôle important. C'est la première chose que les utilisateurs voient de vos modifications.

Sujet
La première ligne du message de validation est connue comme étant le sujet. Le sujet doit avoir une longueur inférieure à 80 caractères (en général 50-70).
 * Résumez vos modifications sur la ligne du sujet. Notez bien que cela restera enregistré dans le dépôt pour toujours.
 * Utilisez le ton impératif pour la ligne du sujet. Le ton impératif semble indiquer que vous donnez des instructions à quelqu'un et peut commencer par des mots comme « Changer », « Corriger », « Ajouter », « Supprimer », « Documenter » « Refactoriser », « etc. ».
 * Des exemples corrects sont « Ajouter Badge::query pour interroger l'API » ou « Eviter les requêtes à l'API dans SimpleBadge » et « Permettre des zéros dans SimpleBadge::add ».
 * De mauvais exemples seraient « méthode ajoutée Badge::query » ou « méthode corrigée Badge::query », « Badge peut appeler l'API », « Badge ne fait pas de requêts à l'API » ou « Les zéros sont autorisés pour ajouter des badges ».
 * La ligne du sujet doit être courte, dites clairement les modifications apportées par votre validation. Il est impossible d'utiliser la même ligne de titre pour deux validations concernant des choses différentes. Les utilisateurs se serviront du titre de votre validation lorsqu'ils le verront passer dans les flux de modifications et les journaux de blâme pour savoir s'ils sont intéressés ou perturbés par le changement. Une ligne de sujet valide permet de décider rapidement si cette validation aura plus d'intérêt qu'une autre pour un sujet ou un problème donné.
 * Exemples corrects : "badger: ajouter les étiquettes d'accessibilité aux champs des formulaires", "rdbms: éviter la boucle infinie quand l'entrée est nulle", ou "htmlform: modifier les couleurs d'écran pour être conforme aux normes d'architecture d'avril 2020".
 * Mauvais exemples : "Implémenter les corrections concernant l'accès", "Ne pas faire planter", ou "Rendre plus joli avec un meilleur agencement".


 * Ne terminez pas la ligne du sujet par un point.
 * Eventuellement, préfixez le sujet avec le composant auquel il se rapporte. Le composant représente le domaine général qui sera modifié par votre validation.

Corps
Lorsque vous rédigez votre texte, posez-vous les questions suivantes :
 * Pourquoi cette modification devrait être faite ? Qu'est-ce qui ne va pas avec le code actuel ?
 * Pourquoi de cette manière ? Y a-t-il d'autres moyens ?
 * Avez-vous envisagé d'autres solutions ? Si c'est le cas, expliquez pourquoi elles n'étaient pas aussi concluantes.
 * Comment un relecteur peut-il tester ou vérifier que votre code fonctionne correctement ?

Recommandé :


 * Séparez le corps du sujet en intercalant une ligne vide.
 * Formatez le message de sorte que les lignes ne dépassent pas 100 caractères. Many editors/tools can do this automatically; 72 characters is a common width to wrap at. Néanmoins ne coupez pas les URLs à la longueur des zones car cela les rendrait non opérationelles; gardez les telles quelles même si elles sont plus longues.
 * Faites référence aux autres validations en utilisant une valeur (courte) de l'identifiant de modification Gerrit telle que, ou un code de hachage Git tel que  . Si la modification correspondante n'a pas encore été fusionnée, utilisez toujours le Change-Id de Gerrit car le code de hachage de la validation Git change une fois la fusion réalisée, ce qui conduirait à une impasse.

Non recommandé :


 * Ne faites pas référence aux autres validations avec une URL ou un numéro de modification.
 * A la place, utilisez l'identifiant de modification Gerrit tel que, ou le code de hachage Git de la validation tel que  . Ce type de hachage est automatiquement converti en un lien permettant d'afficher la modification dans Gerrit, Gitiles et dans les autres navigateurs de dépôt. Ceci vous permet également de naviguer dans le dépôt Git pendant le développement comme via   ou à l'intérieur des éditeurs de texte.
 * D'un autre côté, une URL ne peut être résolue que dans un navigateur web et permet d'atteindre un emplacement fixe, ce qui casse le flux de travail des relecteurs de code et s'écarte du contexte local. For example, inside a Git browser the hash allows you to quickly go from one commit to a related one in the same tool, instead of being sent to Gerrit. Dans Gerrit, vous pouvez aussi chercher le code de hachage pour trouver automatiquement la validation correspondante.
 * Un autre problème est que les numéros de modification peuvent être ambigus ou pointer automatiquement vers une validation différente de celle que vous espériez. Ceci est dû au fait que les codes de hachage sont quelques fois simplement des numéros, par exemle la validation 665661 est différente de la modification 665661.
 * N'employez pas simplement une URL pour expliquer vos modifications.
 * Si les modifications s'appuient sur des discussions données quelque part ou sur une documentation externe, essayez de résumer le ou les points-clés dans votre message de validation et faites également référence à l'URL.

Pied de page et méta données
L'information la plus importante du pied de page est  (obligatoire) et.

Formatez les métadonnées " " et " " exactement comme dans les exemples ci-dessous, et placez les ensemble à la fin du corps, en insérant une ligne vide de séparation.

Voir ci-dessous d'autres informations sur les champs de méta-données individuels.

Exemples


Bon exemple
jquery.badge: Add ability to display the number zero

Cupcake ipsum dolor sit. Amet tart cheesecake tiramisu chocolate cake topping. Icing ice cream sweet roll. Biscuit dragée toffee wypas.

Does not yet address T44834 or T176. Follow-up to Id5e7cbb1.

Bug: T42 Change-Id: I88c5f819c42d9fe1468be6b2cf74413d7d6d6907



Mauvais exemple
Improved the code by fixing a bug.

Changed the files a.php and b.php

Bug: T42 Change-Id: I88c5f819c42d9fe1468be6b2cf74413d7d6d6907



Sujet
La plupart des programmes que nous utilisons et qui affichent le commit de Git, fournissent la ligne du sujet en tant que texte brut. Ce qui signifie que les URLs ne sont pas reconnues, et que la sélection et la copie de texte ne sont souvent pas possibles. C'est pourquoi il ne faut pas référencer les tâches Phabricator, les commit Git, ni les URLs dans la ligne du sujet. Par contre, vous pouvez les placer dans le corps du texte ou dans les métadonnées du pied de page. De cette manière ils seront universellement sélectionnés, copiés, ou cliqués.


 * Gerrit utilise le sujet pour : les notifications par courriel et par IRC, et les résultats de recherche.
 * GitHub utilise le sujet pour : l'historique et le sujet du commit.
 * Le CLI de Git utilise le sujet pour :,  ,  ,  , etc.
 * et plus encore !
 * et plus encore !

Composant
Vous pouvez commencer la ligne du sujet par un composant, ce qui montrera quel domaine du projet est modifié par votre commit.

Il doit être une des valeurs suivantes :
 * Un répertoire de classes PHP sous  ou , tel que « installer », « jobqueue », « objectcache », « resourceloader », « rdbms », etc.
 * Un nom de classe PHP tel que « Title », « User », « OutputPage », etc. ; typiquement pour les classes sans sous-répertoire dans.
 * Un nom de module du chargeur de ressources (ResourceLoader) (tel que « mediawiki.Title », « mediawiki.util », etc.).
 * Un mot-clé générique affectant différents domaines relatifs au type de modification tels que :
 * "build" - pour les modifications de fichiers concernés par le flux de travail du développement, telles que les mises à jour de,  , etc.
 * "tests", "qunit", "phpunit" - pour les modifications ne concernant que les suites de tests unitaires ou de tests d'intégration, ou les lanceurs de suites de tests.

Phabricator
Pour faire référence à un bogue ou à une tâche de, mentionnez-le en ligne dans le message de commit en utilisant la notation Txxx (par exemple That was caused by T169.)

Pour dire qu'un commit résoud (même partiellement) ou qu'il concerne particulièrement un bogue, ajoutez  dans le pied de page, à la fin du message de commit. (si vous faites un amend sur un message commit, ajoutez-le immédiatement au-dessus de la ligne, sans insérer de ligne vide. Rappelez-vous de suivre les règles de structure générales et séparez le corps du sujet par une ligne vide.)

Bug: T169

Un robot va automatiquement laisser un commentaire sur la tâche Phabricator à propos de tout événement significatif qui est survenu (fusionné, interrompu, etc.). Si un patch corrige un ou plusieurs bogues, placez chaque référence  sur une ligne séparée, en bas.

Bug: T299087 Bug: T299088

Cross-références
A chaque fois que vous faites référence à un autre commit, utilisez le code de hachage SHA-1 de Git, correspondant au commit fusionné. Si le commit est encore en cours de revue de code, utilisez le code de hachage du Change-Id de Gerrit au lieu de celui de Git car le code de hachage est relatif à un ensemble de corrections donné (il est différent lors d'un rebase, ce qui provoquerait un cul de sac).

Change-Id
L'outil  de  va ajouter automatiquement le mot-clé   aux nouveaux commits.

Dépendances
Si vous avez des dépendances entre différents dépôts (c'est à dire que votre commit dépend d'un autre commit sur un dépôt qui est différent), déclarez les en ajoutant  au dernier paragraphe. (Ixxx... est le  de l'autre commit.) Ceci indique à Zuul de tester le commit en même temps.



Créditer d'autres personnes
Ajoute cette ligne avant le  pour créditer les autres développeurs travaillant sur la modification. Vous pouvez en ajouter plusieurs en les séparant à chaque fois avec un passage à la ligne.



Lectures complémentaires

 * Node.js Instructions pour le Commit
 * Instructions pour le Git du noyau
 * Instructions pour le commit jQuery
 * Instructions pour le commit Erlang
 * Une note concernant les messages Git de validation (commit) - par Tim Pope
 * Comment écrire un message Git Commit - par Chris Beams
 * Gerrit integrations with the Puppet Catalogue Compiler
 * Comment écrire un message Git Commit - par Chris Beams
 * Gerrit integrations with the Puppet Catalogue Compiler