> For the complete documentation index, see [llms.txt](https://gitbook.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook.com/docs/documentation/fr/collaborer/merge-rules.md). # Règles de fusion Les règles de fusion vous permettent de définir des exigences qui doivent être remplies avant que les demandes de changement puissent être fusionnées, comme l'obligation d'obtenir une revue d'un utilisateur spécifique, ou d'exiger un objet ou une description pour la demande de changement. Ces règles contribuent à maintenir la qualité du contenu et à garantir des processus de revue appropriés tout au long de votre workflow de documentation. Lorsque vous avez configuré des règles de fusion, elles évalueront automatiquement les demandes de changement avant qu'elles ne puissent être fusionnées. Si une règle n'est pas satisfaite, la fusion sera bloquée jusqu'à ce que les exigences soient remplies. Cela fournit un moyen automatisé de faire respecter les normes de collaboration et de revue de votre équipe. ## Utilisation des règles de fusion Vous pouvez configurer des règles de fusion à différents niveaux pour correspondre au workflow de votre équipe : ### Configuration au niveau de l'organisation Les organisations peuvent définir des règles de fusion par défaut que toutes les sections héritent. Cela garantit une cohérence entre plusieurs sections tout en permettant aux sections individuelles de personnaliser leurs règles selon leurs besoins. Pour configurer les règles de fusion pour votre organisation, revenez à votre organisation **Accueil** et cliquez sur **Paramètres** , sous **Administration** dans la barre latérale. Dans l'écran des paramètres, cliquez sur **Règles de fusion** sous le **groupe** Organisation. Ici, vous pouvez définir des règles de fusion pour l'ensemble de votre organisation. Choisissez entre une fusion sans restrictions ou sélectionnez l'un des préréglages pour l'appliquer aux demandes de changement dans l'ensemble de votre organisation. ### Configuration au niveau de la section Que vous ayez ou non activé les règles de fusion à l'échelle de l'organisation, chaque section peut avoir ses propres exigences de fusion adaptées à son contenu et à la structure de son équipe. Cela vous offre la flexibilité d'avoir des règles plus strictes pour la documentation importante et des règles plus souples pour le contenu en brouillon. Lors de la configuration des règles de fusion pour une section, vous pouvez choisir de : * **Hériter** des règles de fusion de votre organisation * **Définir des règles personnalisées** propres à cette section * **Désactiver les règles de fusion** entièrement {% hint style="info" %} Si vous héritez des règles de l'organisation, toute modification des règles de fusion de l'organisation s'appliquera automatiquement à la section. {% endhint %} Pour configurer les règles de fusion d'une section, ouvrez le **menu Actions** :ellipsis: en haut à gauche de l'éditeur, puis cliquez sur **Règles de fusion**. Ici, vous pouvez préciser si vous souhaitez hériter des règles de fusion de votre organisation ou en configurer de nouvelles spécifiques à cette section. ## Évaluation des règles ### Fonctionnement des règles Quand quelqu'un souhaite fusionner une demande de changement, GitBook évaluera toutes les règles configurées dans l'ordre : * Toutes les règles d'une configuration doivent être validées pour qu'une fusion soit autorisée * Les règles sont évaluées dans l'ordre où elles apparaissent dans votre configuration * Si une règle échoue, la fusion est bloquée avec un message d'erreur approprié * Les règles de contournement peuvent annuler les échecs précédents ### Règles de contournement Certaines règles disposent de capacités de contournement (comme **Autoriser des acteurs spécifiés à contourner les exigences**). Ces règles spéciales peuvent annuler les échecs d'autres règles. Si une règle de contournement est évaluée à vrai, la fusion sera autorisée même si d'autres règles ont échoué. ## Bonnes pratiques Lors de la configuration des règles de fusion, tenez compte de ces recommandations : * **Commencez simplement**: Commencez par des règles de base, comme exiger au moins une revue. * **Développez progressivement**: Ajoutez des exigences plus spécifiques à mesure que votre équipe grandit et que vos workflows gagnent en maturité. * **Utilisez le contournement avec prudence**: N'accordez les autorisations de contournement qu'aux administrateurs de confiance. * **Vérifiez régulièrement**: Ajustez les règles en fonction des schémas réels de workflow de votre équipe. * **Testez d'abord**: Dans la mesure du possible, testez les modifications de règles dans une section de test avant de les appliquer aux sections de production. ## Types de règles disponibles ### Exigences de revue
RègleDescription
Exiger au moins une revueGarantit qu'au moins un membre de l'équipe a examiné la demande de changement avant qu'elle ne puisse être fusionnée.
Exiger que toutes les revues soient approuvéesToutes terminées (non demandées) les revues doivent être des approbations. Si un relecteur a demandé des modifications ou a rejeté la demande de changement, la fusion sera bloquée.
Exiger une revue par des acteurs spécifiésNécessite l'approbation de tous les utilisateurs spécifiés. Vous pouvez sélectionner des membres de l'équipe précis qui doivent examiner et approuver la demande de changement avant qu'elle ne puisse être fusionnée.
Exiger une revue par l'un des acteurs spécifiésNécessite l'approbation d'au moins un des utilisateurs spécifiés. C'est utile lorsque vous avez plusieurs relecteurs qualifiés mais n'avez besoin que d'une seule approbation du groupe.
Exiger une revue de Docs Agent (bientôt disponible)Nécessite une revue de l'agent IA de GitBook. Cela garantit que des contrôles automatiques de qualité sont effectués sur les modifications de contenu avant la fusion.
### Exigences de la demande de changement
RègleDescription
Exiger une demande de changement à jourLa demande de changement doit être à jour par rapport à la branche de contenu principale. Si le contenu principal a été mis à jour depuis la création de la demande de changement, vous devrez la rebaser ou la mettre à jour avant de la fusionner.
Exiger un objetLa demande de changement doit avoir un objet/titre descriptif. Les objets vides bloqueront la fusion.
Exiger une descriptionLa demande de changement doit inclure une description expliquant quelles modifications ont été apportées et pourquoi.
### Options avancées
RègleDescription
Autoriser des acteurs spécifiés à contourner les exigencesVous pouvez désigner des utilisateurs spécifiques autorisés à contourner toutes les autres exigences des règles de fusion. C'est utile pour les administrateurs ou les situations d'urgence où les règles doivent être outrepassées.
Expression personnaliséeVous pouvez créer des règles de fusion avancées à l'aide d'expressions JavaScript personnalisées. Cela vous permet de définir une logique complexe basée sur le contexte d'évaluation, avec accès aux propriétés de la demande de changement, des revues et de l'utilisateur qui tente de fusionner.
#### Expressions personnalisées Lorsque vous créez une expression personnalisée, elle sera évaluée chaque fois que quelqu'un essaiera de fusionner une demande de changement. Si l'expression renvoie `vrai`true `false`, la fusion est bloquée. {% hint style="info" %} Les expressions personnalisées prennent en charge la syntaxe JavaScript standard (ES2022) et ont une longueur maximale de 1024 caractères. {% endhint %} **Variables de contexte disponibles :** * `changeRequest.subject` - L'objet/titre de la demande de changement * `changeRequest.description` - La description de la demande de changement * `changeRequest.outdated` - Indique si la demande de changement est obsolète (booléen) * `changeRequest.createdBy.id` - ID de l'utilisateur qui a créé la demande de changement * `reviews` - Tableau d'objets de revue, chacun contenant : * `reviews[].status` - État de la revue (`"approved"` ou `"changes_requested"`) * `reviews[].reviewer.id` - ID du relecteur * `actor.id` - ID de l'utilisateur tentant de fusionner **Exemples courants d'expressions :** {% code title="Exiger plusieurs revues approuvées" %} ```javascript reviews.filter(r => r.status === "approved").length >= 2 ``` {% endcode %} {% code title="Exiger l'approbation d'un utilisateur spécifique" %} ```javascript reviews.some(r => r.reviewer.id === "harry" && r.status === "approved") ``` {% endcode %} {% code title="Exiger une description pour les changements urgents" %} ```javascript !changeRequest.subject.includes("[URGENT]") || !!changeRequest.description ``` {% endcode %} {% code title="Autoriser la fusion par l'auteur uniquement pour les changements mineurs" %} ```javascript changeRequest.createdBy.id === actor.id ? changeRequest.subject.startsWith("[minor]") : true ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://gitbook.com/docs/documentation/fr/collaborer/merge-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.