doc-locale/fr-fr/user/project/merge_requests/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
moved_mr_sidebar a été supprimé.{{< /history >}}
Les merge requests constituent un espace centralisé permettant à votre équipe de réviser le code, d'engager des discussions et de suivre les modifications du code. Pour décrire la raison d'une modification, associez une merge request à un ticket et fermez automatiquement le ticket lors de la fusion de la merge request.
Les merge requests permettent de s'assurer que les experts du domaine examinent vos modifications proposées et que les exigences de sécurité de votre organisation sont respectées. En créant votre merge request tôt dans le processus de développement, votre équipe a le temps de détecter les bugs et les problèmes de qualité du code.
Lors de la consultation d'une merge request, vous voyez :
Une merge request comporte deux rôles :
Les règles et paramètres d'approbation de votre projet déterminent qui peut approuver les merge requests.
Pour plus d'informations, voir assigner une personne assignée et demander un relecteur.
Découvrez les différentes manières de créer une merge request.
Lorsque vous créez une merge request, GitLab vérifie l'existence d'un modèle de description pour ajouter des données à votre merge request. GitLab vérifie ces emplacements dans l'ordre de 1 à 5, et applique le premier modèle trouvé à votre merge request :
| Nom | Interface utilisateur du projet
paramètre | Groupe
default.md | Instance
default.md | Projet
default.md | Aucun modèle |
|:-----|:---------------------:|:---------------------:|:------------------------:|:-----------------------:|:-----------:|
| Message de commit standard | 1 | 2 | 3 | 4 | 5 |
| Message de commit avec un modèle de fermeture de ticket comme Closes #1234 | 1 | 2 | 3 | 4 | 5 * |
| Nom de branche préfixé d'un identifiant de ticket, comme 1234-example | 1 * | 2 * | 3 * | 4 * | 5 * |
[!note] Les éléments marqués d'un astérisque (*) ajoutent également un modèle de fermeture de ticket.
Vous pouvez afficher les merge requests pour votre projet, votre groupe ou vous-même.
{{< tabs >}}
{{< tab title="Pour vous-même" >}}
Pour afficher toutes les merge requests nécessitant votre participation, utilisez l'une des options suivantes :
{{< /tab >}}
{{< tab title="Pour un projet" >}}
Pour afficher toutes les merge requests d'un projet :
Ou, pour utiliser un raccourci clavier, appuyez sur <kbd>g</kbd>+<kbd>m</kbd>.
{{< /tab >}}
{{< tab title="Pour tous les projets d'un groupe" >}}
Pour afficher les merge requests de tous les projets d'un groupe :
Si votre groupe contient des sous-groupes, cette vue affiche également les merge requests des projets du sous-groupe.
{{< /tab >}}
{{< tab title="Pour un fichier" >}}
Lorsque vous consultez un fichier dans votre dépôt, GitLab affiche un badge indiquant le nombre de merge requests ouvertes qui ciblent la branche actuelle et modifient le fichier. Le badge vous aide à identifier les fichiers présentant des modifications en attente.
La disponibilité de cette fonctionnalité est contrôlée par un feature flag. Pour plus d'informations, voir afficher les merge requests ouvertes pour un fichier.
Pour afficher les merge requests ouvertes pour un fichier :
{{< /tab >}}
{{< /tabs >}}
{{< history >}}
source branch introduit dans GitLab 16.6.merged by introduit dans GitLab 16.9. Disponible uniquement lorsque le feature flag mr_merge_user_filter est activé.merged by disponible de manière générale dans GitLab 17.0. L'indicateur de fonctionnalité mr_merge_user_filter a été supprimé.merged before et merged after introduit dans GitLab 18.6.{{< /history >}}
Pour filtrer la liste des merge requests :
#30 pour ne retourner que la merge request 30.= : Est!= : N'est pasAND logique.Pour filtrer les merge requests par données de déploiement, telles que l'environnement ou une date, vous pouvez saisir (ou sélectionner dans la liste déroulante) les éléments suivants :
[!note] Les projets qui utilisent une méthode de fusion fast-forward ne renvoient pas de résultats, car cette méthode ne crée pas de commit de fusion.
Pour filtrer par environnement, sélectionnez une option dans la liste déroulante des environnements disponibles.
Pour filtrer par Deployed before ou Deployed after, saisissez manuellement une date de déploiement :
YYYY-MM-DD. Pour spécifier à la fois une date et une heure, utilisez des guillemets doubles ("YYYY-MM-DD HH:MM").Si vous avez la permission d'ajouter des modifications à une merge request, vous pouvez le faire de plusieurs façons. La méthode à utiliser dépend de la complexité de votre modification et de la nécessité d'accéder à un environnement de développement :
Pour assigner la merge request à un utilisateur, utilisez l'action rapide /assign @user dans une zone de texte d'une merge request, ou :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et accédez à votre projet.
Dans la barre latérale gauche, sélectionnez Code > Requêtes de fusion et trouvez votre merge request.
Dans la barre latérale droite, dans la section Personnes assignées, sélectionnez Modifier.
Recherchez l'utilisateur que vous souhaitez assigner, puis sélectionnez-le. Avec GitLab Free, vous pouvez assigner un seul utilisateur par merge request. Avec GitLab Premium et GitLab Ultimate, vous pouvez assigner plusieurs utilisateurs :
GitLab ajoute la merge request à la page Requêtes de fusion assignées de l'utilisateur.
Les participants sont des utilisateurs qui ont interagi avec une merge request. Pour obtenir des informations sur la consultation des participants, voir participants.
Pendant le processus de revue de la merge request, les relecteurs fournissent des retours sur vos modifications. Lorsqu'un relecteur est satisfait des modifications, il peut configurer la merge request en fusion automatique, même si certaines vérifications de fusion échouent. Une fois toutes les vérifications de fusion réussies, la merge request est automatiquement fusionnée, sans autre action de votre part.
Permissions de fusion par défaut :
main, est protégée.Pour déterminer si vous avez la permission de fusionner une merge request spécifique, GitLab vérifie :
Si vous décidez d'arrêter définitivement les travaux sur une merge request, clôturez-la plutôt que de la supprimer.
Prérequis :
Pour clore une merge request dans le projet :
GitLab clôture la merge request, mais conserve les enregistrements de la merge request, ses commentaires et tous les pipelines associés.
{{< history >}}
{{< /history >}}
Pour supprimer la branche source d'une merge request :
Un administrateur peut définir cette option comme valeur par défaut dans les paramètres du projet.
L'utilisateur qui configure la fusion automatique ou fusionne la merge request effectue la suppression de la branche. Si cet utilisateur ne dispose pas du rôle approprié, par exemple dans un projet dupliqué, la suppression de la branche source échoue.
{{< details >}}
{{< /details >}}
Les merge requests sont souvent enchaînées, l'une dépendant du code ajouté ou modifié dans une autre merge request. Pour prendre en charge des merge requests petites et individuelles, GitLab peut mettre à jour jusqu'à quatre merge requests ouvertes lorsque leur branche cible fusionne dans main. Par exemple :
feature-alpha dans main.feature-beta dans feature-alpha.Si ces merge requests sont ouvertes en même temps, et que la merge request 1 (feature-alpha) fusionne dans main, GitLab met à jour la destination de la merge request 2 de feature-alpha vers main.
Les merge requests avec des mises à jour de contenu interconnectées sont généralement traitées de l'une des manières suivantes :
main. La merge request 2 est ensuite reciblée vers main.feature-alpha. La merge request 1 mise à jour, qui contient maintenant le contenu de feature-alpha et de feature-beta, fusionne dans main.Cette fonctionnalité ne fonctionne que lorsqu'une merge request est fusionnée. La sélection de Remove source branch après la fusion ne reciblant pas les merge requests ouvertes. Cette amélioration est proposée comme suivi.
Pour un développeur ou une développeuse qui travaille en équipe :
Pour un développeur ou une développeuse web qui rédige une page web pour le site de votre entreprise :
{{< history >}}
mr_activity_filters activé sur GitLab.com dans GitLab 16.0.mr_activity_filters a été supprimé.{{< /history >}}
Pour comprendre l'historique d'une merge request, filtrez son fil d'activité pour n'afficher que les éléments pertinents pour vous.
Dans la barre supérieure, sélectionnez Rechercher ou aller à et accédez à votre projet.
Dans la barre latérale gauche, sélectionnez Code > Requêtes de fusion.
Sélectionnez une merge request.
Faites défiler jusqu'à Activité.
Sur le côté droit de la page, sélectionnez Activity filter pour afficher les options de filtre. Si vous avez déjà sélectionné des options de filtre, ce champ affiche un résumé de vos choix, comme Activity + 5 more.
Sélectionnez les types d'activité que vous souhaitez voir. Les options incluent :
facultatif. Sélectionnez Sort ({{< icon name="sort-lowest" >}}) pour inverser l'ordre de tri.
Votre sélection persiste pour toutes les merge requests. Vous pouvez également modifier l'ordre de tri à l'aide du bouton de tri situé à droite.
Les discussions dans une merge request comprennent des commentaires simples et des fils de commentaires. Les fils de discussion ouverts (non résolus) bloquent la fusion d'une merge request, mais pas les commentaires simples. Lorsqu'une discussion dans un fil de discussion est terminée, résolvez le fil de discussion pour réduire son affichage. Si un fil de commentaires est important mais ne doit pas bloquer la merge request, déplacez-le vers un ticket pour poursuivre la discussion.
GitLab affiche le nombre de fils de discussion ouverts dans le coin supérieur droit d'une merge request. Cette merge request comporte trois fils de discussion ouverts :
Pour afficher tous les commentaires dans les fils de discussion réduits, développez les fils de discussion :
Pour déplacer les fils de discussion ouverts vers un nouveau ticket et débloquer une merge request :
{{< tabs >}}
{{< tab title="Déplacer un fil de discussion" >}}
Si vous avez un fil de discussion ouvert spécifique dans une merge request, vous pouvez créer un ticket pour le résoudre séparément :
GitLab marque le fil de discussion comme résolu et ajoute un lien depuis la merge request vers le nouveau ticket.
{{< /tab >}}
{{< tab title="Déplacer tous les fils de discussion ouverts" >}}
Si vous avez plusieurs fils de discussion ouverts dans une merge request, vous pouvez créer un ticket pour les résoudre séparément :
GitLab marque tous les fils de discussion comme résolus et ajoute un lien depuis la merge request vers le nouveau ticket.
{{< /tab >}}
{{< /tabs >}}
Vous pouvez empêcher la fusion des merge requests tant que des fils de discussion restent ouverts. Lorsque vous activez ce paramètre, le compteur Open threads dans une merge request apparaît en orange tant qu'au moins un fil de discussion reste ouvert.
Vous pouvez configurer les merge requests pour résoudre automatiquement les fils de discussion lorsqu'un nouveau push modifie les lignes que ces fils de discussion décrivent.
Les fils de discussion sont désormais résolus si un push rend une section diff obsolète. Les fils de discussion sur les lignes inchangées et les fils de discussion résolvables de niveau supérieur ne sont pas résolus.
{{< details >}}
{{< /details >}}
{{< history >}}
notifications_todos_buttons. Désactivée par défaut.{{< /history >}}
[!flag] La disponibilité de cette fonctionnalité est contrôlée par un feature flag. Pour plus d'informations, consultez l'historique.
Lorsque vous activez ce feature flag, les boutons de notifications et d'éléments de la liste de tâches se déplacent vers le coin supérieur droit de la page.