---
{
"title": "Créér une demande de retrait",
"language": "fr",
"description": "Comment créer une demande de retrait",
"altLangPrefix": "pull",
"dateModified": "2014-08-08"
}
---
Les demandes de retrait (Pull requests) sont bienvenues. Veuillez vous assurer que vos modifications sont à jour et limitez la portée d'engagement (commit)
seulement aux fichiers que vous désirez modifier (pour éviter des conflits).
Pour réduire la pollution d'engagement dans la base de code principale, considérez rebaser vos engagements avant de créer
une demande de retrait de la branche principale.
Nouvelles composantes
Devraient être ajoutées dans une branche feature-* (p.e., feature-lightbox) qui est créé à partir de la branche maître (master).
Créer une nouvelle branche du maître en utilisant :
git fetch upstream
git checkout upstream/master
git checkout -b my-cool-new-feature
L'accord de licence pour toutes les nouvelles composantes et code de support doit être compatible avec la licence MIT utilisée par la BOEW.
Les nouveaux modules d'extension devraient utiliser la même structure et format que les modules d'extension existants.
Inclure le bloc commentaire d'avis à l'intérieur de tout fichiers sources à base textuelle qui dérivent du droit d'auteur de la Couronne.
Correction d'anomalies et déploiements de correctifs qui s'appliquent à toutes les versions
Devraient être soumises à la branche maître.
Créer une nouvelle branche du maître en utilisant :
git fetch upstream
git checkout upstream/master
git checkout -b my-patch-description
Tester votre rapiécage avant de soumettre
Validez vos balises HTML pour vous assurer du HTML5 bien formé.
Ces tests seront exécutés comme partie de l'intégration (build) par défaut, ou en apellant grunt htmllint pour exécuter la tâche sur votre construction HTML.
Vous pouvez manuellement tester pour des balises bien formées en utilisant le validateur HTML W3C, validez avec une paramètre XHTML5
et un crochet à "Be lax about HTTP Content-Type".
Validez votre CSS avec les changements suivants aux paramètres par défaut:
Utiliser des double guillemets pour des chaînes de caractères en JavaScript (pour que les guillemets simples non échappés
puissent être utilisés pour des attributs dans le code de sortie HTML).
Tester les pages Web contre la base de test des fureteurs suivants :
Les versions majeures courante et précédente de chaque fureteur qui compte pour au moins 5 pourcent des visitesFootnote 1 sur le site Web;
N'importe quelle version majeure d'un fureteur qui, par lui même, compte pour 5 pourcent des visitesFootnote 1 du site Web; et
La version majeure courante de fureteur mobile qui compte pour au moins 5 pourcent des visitesFootnote 1 sur le site Web effecutées avec les appareils mobiles.
Les tests sur les déploiements de correctifs sont exécutés par Travis-CI, mais la même batterie de tests peut être exécutée en utilisant grunt dist localement avant de soumettre.
Commit Messages
Needs translation
When committing changes for a pull request, your commit message should start off with the name of the affected plugin(s) or topic, followed by a colon and a short description of what's changed. A longer description can also optionally be included. If the commit resolves a pre-existing issue on GitHub, include "Fixes #issue-id." as a part of the long description.
Message example
Plugin name/topic: Short description of the change. (Optional) Long description of the change. Fixes #1715.
Command line example
git commit -m "Plugin name/topic: Short description of the change." -m "(Optional) Long description of the change. Fixes #1715."