Devolutions/IronRDP

Conventions de commit et de PR

Traitez le titre et le corps initial de la PR comme le message de commit exact qui sera appliqué lors de la fusion par squash.

Message de commit

• Lisez d'abord les instructions du dépôt. Dérivez les portées avec la compétence locale commit-scope du dépôt. Si indisponible, utilisez les règles explicites du dépôt ou omettez la portée plutôt que d'en inventer une.
• Suivez les Conventional Commits : <type>[portée optionnelle][!] : <description>.
• Visez 50 caractères et décrivez le comportement résultant. Ne supprimez pas les portées obligatoires du dépôt pour atteindre cet objectif ; lorsque cela les rend impossibles, gardez la description restante aussi concise que possible.
• Séparez le sujet, le corps et les pieds de page par des lignes vides.
• Pour les commits individuels, limitez les lignes du corps à 72 caractères. Expliquez pourquoi la modification était nécessaire, comment elle résout le problème, et les effets secondaires matériels.
• Placez une clé de ticket existante ou un lien dans un pied de page, pas dans le sujet : Issue : PROJET-123. Respectez le format de pied de page spécifique au dépôt lorsqu'un ticket existe. En l'absence de ticket, omettez le pied de page plutôt que d'inventer Issue : N/A.
• Ajoutez les pieds de page Conventional Commits applicables et les mentions Co-authored-by : Nom <email> pour les collaborateurs.
• Choisissez le type en fonction de la surface affectée, et non du fait que la modification corrige un défaut.
• Utilisez ci pour les modifications d'intégration continue, de workflow et d'automatisation, y compris les corrections de cette automatisation.
• Utilisez fix pour les bogues de produit ou d'exécution et les modifications non fonctionnelles des interfaces API publiques consommées en externe.
• Utilisez feat pour les fonctionnalités, build pour la construction ou les dépendances, chore pour les outils ou la configuration non liés au produit, docs pour la documentation uniquement, style pour les modifications non sémantiques, refactor pour la restructuration interne, test pour les tests, et perf pour les performances.
• Marquez les modifications cassantes avec ! ou un pied de page BREAKING CHANGE sans modifier un type par ailleurs exact.
• Conservez chaque commit de développement non squashed cohérent et conventionnel.

fix(stockage) : préserver les index collationnés

Normaliser les collations étendues par le serveur avant de comparer les définitions d'index.

Issue : PROJET-123

Pull request

• Définissez le titre exactement comme le sujet du commit de squash prévu.
• Définissez le corps initial exactement comme le corps et les pieds de page du commit de squash prévu. Excluez les préambules, listes de contrôle et journaux d'implémentation propres à la PR.
• Ne faites pas de retour à la ligne manuel dans le corps de la PR ; GitHub gère le retour à la ligne d'affichage.
• Gardez l'historique permanent concis : rapportez la motivation, le comportement matériel et les effets secondaires.
• Placez les expériences, alternatives, validations approfondies et la chronologie de l'implémentation dans des commentaires de suivi.
• Publiez un commentaire de suivi avec les lignes modifiées, réparties au moins entre le code de production, les tests et les autres fichiers, afin qu'un relecteur voie où se situe le poids de la modification avant de la lire ; la manière de les compter et de les présenter vous revient, et actualisez-le lorsque le diff change de manière substantielle.
• Mettez à jour le titre et le corps initial au fur et à mesure que l'implémentation évolue.
• Avant d'ouvrir, de mettre à jour ou de fusionner, lisez titre + ligne vide + corps comme un seul message de commit et corrigez toute incohérence.