GitLab - 6.10 Demande de fusion (merge request) dans GitLab : du push à la fusion
Quand plusieurs personnes travaillent sur le même dépôt Git, on évite de pousser directement sur la branche principale. Une demande de fusion, ou merge request, permet de proposer une modification, de la faire relire et de lancer les tests avant de l'intégrer. Cette leçon suit toutes les étapes, de la branche locale jusqu'à la fusion dans GitLab.
Préparer la branche et la pousser
Avant de commencer, on récupère les dernières modifications du dépôt distant pour travailler sur une base à jour. On crée ensuite une branche de fonctionnalité ou de correctif, qui isole le travail du reste du projet.
Une fois les modifications validées par un commit, la branche doit être poussée vers le dépôt distant. Tant qu'elle n'est pas poussée, elle n'apparaît pas dans l'interface GitLab. Le nom doit être exactement celui créé localement.
git add <fichier>
git commit -m "<message-de-validation>"
git push origin <nom-de-la-branche>Ouvrir la demande de fusion
Après le push, GitLab propose un lien pour créer une demande de fusion. Le titre et la description expliquent le changement, pour que les relecteurs comprennent pourquoi il est fait. Une bonne description facilite la relecture.
Si le projet contient un pipeline d'intégration continue, il démarre automatiquement et exécute les tests. Si les tests échouent, le bouton de fusion reste désactivé. Selon l'organisation, la demande peut aussi exiger l'approbation d'une ou de plusieurs personnes.
La liste des demandes de fusion se trouve dans le menu de gauche. Chaque demande affiche son statut et son pipeline, ce qui permet de suivre le travail de l'équipe d'un coup d'œil. Une option permet de supprimer la branche source après l'acceptation.
Mettre à jour et fusionner
Chaque nouveau commit poussé sur la branche s'ajoute automatiquement à la demande de fusion. Si quelqu'un a modifié la branche principale entre-temps, GitLab vérifie s'il existe un conflit. Lorsqu'il n'y a pas de conflit, un bouton permet de rebaser la branche depuis l'interface.
Écraser les commits transforme plusieurs commits en un seul, ce qui garde un historique propre. Dans les paramètres de fusion, la fusion rapide évite un commit de fusion supplémentaire. Ces options dépendent du niveau d'accès au dépôt.
Après la fusion, la demande passe au statut fusionné et le commit apparaît dans la branche principale. Il reste important de garder la branche locale synchronisée avec la branche distante.
En résumé
Une demande de fusion organise le travail d'équipe. On pousse une branche, on ouvre la demande, on attend les tests et les relectures, puis on fusionne. L'écrasement des commits et la fusion rapide gardent un historique lisible, et l'interface permet de rebaser sans conflit.
Points clés
- La demande de fusion propose un changement avant son intégration dans la branche principale.
- Une branche doit être poussée vers le dépôt distant pour apparaître dans GitLab.
- Un pipeline en échec bloque le bouton de fusion.
- L'écrasement des commits donne un historique plus propre.
- La fusion rapide évite les commits de fusion inutiles.
Questions fréquentes
Pourquoi ne pas pousser directement sur la branche principale ?
Une demande de fusion permet aux tests et aux collègues de vérifier la modification avant son intégration. Cela réduit le risque de casser le projet.
Que se passe-t-il si la branche principale a changé ?
GitLab vérifie s'il existe un conflit. La vidéo montre le rebasage depuis l'interface dans le cas où il n'y a pas de conflit.
Faut-il écraser les commits à chaque fois ?
La vidéo présente l'écrasement comme un moyen d'obtenir un historique propre, souvent avant la fusion. Le choix dépend des habitudes de l'équipe.