Comment envoyer des pull requests

Pour apporter des modifications au contenu, envoyez une pull request à partir de votre fork. Une demande de fusion doit être examinée avant d'être fusionnée. Pour obtenir de meilleurs résultats, passez en revue la liste de contrôle éditoriale avant de soumettre votre demande de tirage.

Utilisation de branches Git

La branche par défaut pour PowerShell-Docs est la main branche. Les modifications apportées dans les branches de travail sont fusionnées dans la main branche avant d’être publiées. La branche main est fusionnée dans la branche live tous les jours de semaine à 15h00 (Heure du Pacifique). La live branche contient le contenu publié dans learn.microsoft.com.

Avant de commencer les modifications, créez une branche de travail dans votre copie locale du référentiel PowerShell-Docs. Lorsque vous travaillez localement, veillez à synchroniser votre référentiel local avant de créer votre branche de travail. La branche de travail doit être créée à partir d'une copie datée up-tode la branche main.

Toutes les pull requests doivent cibler la branche main. N’envoyez pas de modifications dans la branche live. Les modifications apportées dans la main branche sont fusionnées en liveremplaçant les modifications apportées à live.

Améliorer le processus de pull request pour tout le monde

Plus votre pull request est simple et ciblée, plus elle peut être examinée et fusionnée rapidement.

Éviter les pull requests qui mettent à jour un grand nombre de fichiers ou contiennent des modifications sans rapport.

Évitez de créer des pull requests contenant des modifications non liées. Séparez les mises à jour mineures des articles existants des nouveaux articles ou des réécritures majeures. Travaillez sur ces changements dans des branches de travail distinctes.

Les modifications en bloc créent des demandes de fusion avec un grand nombre de fichiers modifiés. Limitez vos demandes de tirage à un maximum de 50 fichiers modifiés. Les demandes de tirage volumineuses sont difficiles à examiner et sont plus sujettes à des erreurs.

Renommer ou supprimer des fichiers

Il doit y avoir un problème lié à la pull request lorsque vous renommez ou supprimez des fichiers. Ce problème doit discuter de la nécessité de renommer ou de supprimer les fichiers.

Évitez de mélanger les ajouts de contenu ou les modifications avec les renommages et suppressions de fichiers. Tout fichier que vous renommez ou supprimez doit être ajouté au fichier de redirection approprié. Si possible, mettez à jour tous les fichiers liés au contenu renommé ou supprimé, y compris les fichiers TOC.

Éviter de modifier les fichiers de configuration du référentiel

Évitez de modifier les fichiers de configuration du référentiel. Limitez vos modifications lorsque cela est possible aux fichiers de contenu Markdown et aux fichiers image de prise en charge nécessaires au contenu.

Les modifications incorrectes apportées aux fichiers de configuration du référentiel peuvent interrompre la génération, introduire des vulnérabilités ou des problèmes d’accessibilité, ou violer les normes organisationnelles. Les fichiers de configuration du référentiel sont tous les fichiers qui correspondent à un ou plusieurs de ces modèles :

• *.yml
• .github/**
• .localization-config
• .openpublishing*
• LICENSE*
• reference/docfx.json
• reference/mapping/**
• tests/**
• ThirdPartyNotices
• tools/**

Pour la sûreté et la sécurité, ne modifiez pas ces fichiers. Si vous pensez qu’un de ces fichiers doit être modifié, faites un problème. Une fois que les mainteneurs auront évalué le problème, ils apporteront les changements appropriés.

Utiliser le modèle de demande de tirage

Lorsque vous créez une demande de tirage, un modèle est automatiquement inséré dans le corps de la demande de tirage pour vous. Il ressemble à ceci :

# PR Summary

<!--
    Delete this comment block and summarize your changes and list
    related issues here. For example:

    This changes fixes problem X in the documentation for Y.

    - Fixes #1234
    - Resolves #1235
-->

## PR Checklist

<!--
    These items are mandatory. For your PR to be reviewed and merged,
    ensure you have followed these steps. As you complete the steps,
    check each box by replacing the space between the brackets with an
    x or by clicking on the box in the UI after your PR is submitted.
-->

- [ ] **Descriptive Title:** This PR's title is a synopsis of the changes it proposes.
- [ ] **Summary:** This PR's summary describes the scope and intent of the change.
- [ ] **Contributor's Guide:** I have read the [contributors guide][contrib].
- [ ] **Style:** This PR adheres to the [style guide][style].

<!--
    If your PR is a work in progress, please mark it as a draft or
    prefix it with "(WIP)" or "WIP:"

    This helps us understand whether or not your PR is ready to review.
-->

[contrib]: /powershell/scripting/community/contributing/overview
[style]: /powershell/scripting/community/contributing/powershell-style-guide

Dans la section « Résumé du PR », écrivez un bref résumé de vos modifications et répertoriez les problèmes connexes par leur numéro de problème, par exemple #1234. Si votre pull request répare ou résout le problème, utilisez la fonction de fermeture automatique de GitHub afin que le problème soit automatiquement fermé lorsque votre pull request est fusionnée.

Passez en revue les éléments de la section « Liste de contrôle des RP » et cochez-les au fur et à mesure que vous terminez chacun d’eux. Vous devez suivre les instructions et vérifier chaque point pour que l’équipe approuve votre requête de fusion.

Si votre pull request est un travail en cours, définissez-la en mode brouillon ou préfixez le titre de votre pull request avec WIP.

Commentaires sur les attentes

Une fois que vous avez envoyé votre pull request, un bot commentera votre pull request. Le commentaire fournit des ressources et définit les attentes pour le reste du processus. Nous pouvons mettre à jour ce commentaire régulièrement, donc toujours passer en revue le commentaire, même si ce n’est pas votre première contribution.

Service de validation de PR Docs

Le service de validation docs PR est une application GitHub qui exécute des règles de validation sur vos modifications. Vous devez corriger les erreurs ou avertissements signalés par le service de validation.

Les étapes suivantes décrivent le comportement de validation :

1. Vous soumettez une demande de tirage.

2. Dans le commentaire GitHub qui indique l’état des « vérifications » activées sur le référentiel. Dans cet exemple, il y a deux vérifications activées : « Commit Validation » et « OpenPublishing.Build ».

   

   La construction peut passer même si la validation du commit échoue.

3. Sélectionnez Détails pour plus d’informations. La page Détails affiche toutes les vérifications de validation ayant échoué et inclut des informations sur la façon de résoudre les problèmes.

4. Une fois la validation réussie, le commentaire suivant est ajouté à la demande de tirage :

   

Remarque

Si vous êtes un contributeur externe (et non un employé Microsoft), vous n’avez pas accès aux rapports de build détaillés ou aux liens d’aperçu.

Lorsque la demande de tirage est examinée, vous pouvez être invité à apporter des modifications ou à corriger les messages d’avertissement de validation. L’équipe PowerShell-Docs peut vous aider à comprendre les erreurs de validation et les exigences éditoriales.

GitHub Actions (actions de GitHub)

Plusieurs actions GitHub différentes s’exécutent sur vos modifications pour valider et fournir un contexte pour vous et les réviseurs.

Vérification de la liste de contrôle

Si votre demande de tirage n’est pas en mode brouillon et n’est pas précédée WIPd’un préfixe, une action GitHub inspecte votre demande de tirage pour vérifier que vous avez sélectionné chaque élément de la liste de contrôle du modèle de demande de tirage. Les responsables ne passeront pas en revue ni ne fusionneront votre demande de validation tant que vous n’aurez pas terminé la liste de contrôle. Les éléments de liste de contrôle sont obligatoires.

Vérification de l’autorisation

Si votre pull request cible la branche live ou modifie des fichiers de configuration du référentiel, une Action GitHub vérifie vos autorisations pour confirmer votre autorisation de soumettre ces modifications.

Seuls les administrateurs de référentiels sont autorisés à cibler la live branche ou à modifier les fichiers de configuration du référentiel.

Rapports de changement de contenu versionné

Si votre demande de tirage ajoute, supprime ou modifie tout contenu versionné, une action GitHub analyse vos modifications et écrit un rapport récapitulé les types de modifications apportées au contenu versionné.

Ce rapport peut indiquer s’il existe d’autres versions des fichiers que vous devez mettre à jour dans cette demande de tirage.

Pour trouver le rapport de contenu versionné pour votre demande de tirage :

1. Sélectionnez l’onglet « Vérifications » dans votre page de demande de tirage.
2. Sélectionnez le travail « Création de rapports » dans la liste des travaux.
3. Sélectionnez le bouton « ... » en haut à droite.
4. Sélectionnez « Afficher le résumé du travail ».

Étapes suivantes

guide de stylePowerShell-Docs

Ressources supplémentaires

Comment nous gérons les pull requests