Partager via

Gestion des pull requests

Cet article explique comment nous gérons les requêtes de tirage dans le référentiel PowerShell-Docs. Cet article est conçu pour être une aide professionnelle pour les membres de l’équipe PowerShell-Docs. Nous publions ces informations ici pour assurer la transparence des processus pour nos contributeurs publics.

Meilleures pratiques

  • Demandez une révision. La personne qui soumet la demande de tirage ne doit pas fusionner la demande de tirage sans examen par les pairs.
  • Affectez le réviseur homologue lorsque la demande de tirage est envoyée. L’affectation anticipée permet au réviseur de répondre plus tôt avec des remarques éditoriales.
  • Utilisez des commentaires pour décrire la nature de la modification en cours d’envoi. Par exemple, si la modification est mineure, expliquez la modification et que vous n’avez pas besoin d’une révision technique complète. Assurez-vous de @mention le réviseur.
  • Utilisez la fonctionnalité de suggestion de commentaire pour faciliter l’acceptation de la modification suggérée par l’auteur. Pour plus d’informations, voir Révision des modifications proposées dans un pull request.

Étapes du processus de relations publiques

  1. Writer : Créer une Pull Request
    • Remplir le modèle de RP
    • Associer les problèmes résolus par le pull request
    • Utiliser la fonctionnalité de fermeture automatique de GitHub pour fermer le problème
    • Parcourir et vérifier chaque élément de la liste de contrôle
  2. Écrivain : Affecter un réviseur par les pairs
  3. Réviseur : vérifications et commentaires (si nécessaire)
  4. Rédacteur : Incorporer les commentaires du examen
  5. Les deux : Passer en revue le rendu en préversion
  6. Les deux : passer en revue le rapport de validation - corriger les avertissements et les erreurs
  7. Réviseur : Marquer la révision « Approuvée »
  8. Maintenance du dépôt : fusion de demande de tirage

Liste de contrôle du réviseur de contenu

Consultez la liste de contrôle éditoriale pour obtenir une liste plus complète.

  • Vérification linguistique pour la grammaire, le style, la concision, la précision technique
  • Vérifier que les exemples s’appliquent toujours à la version cible
  • Vérifier le rendu en préversion
  • Vérifier les métadonnées - ms.date, supprimer ms.assetid, vérifier les champs obligatoires
  • Valider la validité du markdown
    • Consultez le guide de style pour connaître les règles de mise en forme spécifiques au contenu
  • Réorganiser les exemples comme suit :
    • Paragraphe d’introduction
    • code et sortie ;
    • Explication détaillée du code (si nécessaire)
  • Vérifier la précision des liens hypertexte
    • Remplacer ou supprimer des liens TechNet/MSDN
    • Garantir le nombre minimal de redirections vers la cible
    • Vérifier HTTPS
    • Type de lien correct
      • Liens de fichiers pour les fichiers locaux
      • Liens d’URL pour les fichiers en dehors de l’ensemble de documents
    • Supprimer les paramètres régionaux des URL
    • Simplifier les URL pointant vers learn.microsoft.com
  • Vérifiez que le contenu versionné est correct dans toutes les versions.

Processus de fusion de branche

La main branche est la seule branche qui doit être fusionnée dans live. Les fusions de branches de courte durée (de travail) doivent être écrasées avant de fusionner en main.

Fusionner depuis/vers branche-de-sortie principal en direct
branche de travail compacter et fusionner compacter et fusionner Non autorisé
branche-de-sortie — fusion Non autorisé
principal rebaser — fusion

Liste de contrôle de fusion des pull requests

  • Révision de contenu terminée
  • Branche cible correcte pour la modification
  • Aucun conflit de fusion
  • Toutes les étapes de validation et de génération sont réussies.
    • Les avertissements et suggestions doivent être corrigés (voir Remarques pour les exceptions)
    • Aucun lien rompu
    • L’action Check-list s’est exécutée et passée
    • Si une vérification d’autorisation a été déclenchée, elle a réussi
  • Fusionner selon le tableau

Remarques

Les avertissements suivants peuvent être ignorés :

Can't find service name for `<version>/<modulepath>/About/About.md`

Metadata with following name(s) are not allowed to be set in YAML header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

Lorsqu'une pull request est fusionnée, le HEAD de la branche cible est modifié. Les pull requests ouvertes qui étaient basées sur le précédent HEAD sont maintenant obsolètes. Un mainteneur a le droit de passer outre les avertissements de fusion et de fusionner la pull request périmée sur GitHub. La fusion d’un PR obsolète est sécurisée si les PR précédemment fusionnés n’ont pas touché les mêmes fichiers.

Pour mettre à jour le pull request, sélectionnez le bouton Update Branch. Choisissez l'option Mettre à jour avec rebase. Pour plus d’informations, consultez Mise à jour de votre branche de pull request.

Publication en direct

Les modifications accumulées dans la main branche doivent régulièrement être publiées sur le site web en ligne.

  • La main branche est fusionnée à live chaque jour de la semaine à 3h PST.
  • La main branche doit être fusionnée live après toute modification significative.
    • Modifications apportées à 50 fichiers ou plus
    • Après la fusion d’une branche de mise en production
    • Modifications apportées aux configurations de référentiel ou docset (docfx.json, configurations OPS, scripts de génération, etc.)
    • Modifications apportées au fichier de redirection
    • Modifications apportées au TOC
    • Après avoir fusionné une branche « projet » (reorgation de contenu, mise à jour en bloc, etc.)
  • Last updated on