Merge requests (GitLab)

Une merge request (MR) est la demande de merger une branche dans une autre (sur GitHub c'est des pull request). C'est là qu'on fait la revue par un pair et que la CI vérifie le code avant qu'il arrive sur main.

Flux attendu

main ──► branche de travail ──► commits ──► push ──► pipeline de branche
                                                          │
                                  revue par un pair ◄─────┘
                                          │
                                   merge request vers main ──► pipeline de MR
                                          │
                                       merge ──► tag de version

1. créer une branche depuis main (on ne travaille pas directement sur main)
2. faire des commits réguliers, avec des messages conventional commits
3. pousser la branche: ça peut lancer une pipeline (selon le workflow)
4. ouvrir la MR vers main: ça lance la pipeline de MR
5. si tout est vert et la revue OK, merger
6. sur main, tagger la version (v1.0.0...)

Créer la MR

Après un push, GitLab affiche une bannière "Create merge request". Sinon: menu de gauche, Merge requests > New merge request, choisir la branche source (exercice) et la cible (main), un titre, une description.

Dès que la MR existe, une pipeline de MR démarre (si le workflow l'autorise, voir rules et workflow). C'est la pipeline avec $CI_PIPELINE_SOURCE == "merge_request_event".

merger avec un message conforme

Au moment de merger, GitLab propose des options:

Option	Effet
Delete source branch	supprime la branche source après la merge
Squash commits	écrase tous les commits de la branche en un seul
Edit commit message	permet de changer le message du commit de merge (et de squash)

Attention

Le message par défaut du commit de merge est Merge branch 'exercice' into 'main'. Il ne respecte pas conventional commits. Quand la consigne dit "tous les messages de commit, y compris ceux des commits de merge", il faut cocher Edit commit message et écrire quelque chose comme:

feat(ci): ajout des jobs bonjour-mr et appel-api

Après la merge

La merge s'est faite sur le serveur, donc le main local est en retard:

git checkout main
git pull
git branch -d exercice  # supprimer la branche locale (déjà mergée)
git fetch --prune       # nettoyer les branches distantes disparues

Ensuite, on tag (voir commandes git):

git tag v0.0.1
git push origin v0.0.1

Conflits dans une MR

Si GitLab dit qu'il y a des conflits, deux solutions:

• les résoudre dans l'interface web (le plus simple)
• ou en local: merger main dans la branche, résoudre à la main (marqueurs <<<<<<<), puis pousser

git checkout exercice
git merge main
# éditer les fichiers en conflit, supprimer les marqueurs
git add fichier
git commit              # message conventional commits
git push

La branche par défaut

C'est la branche cible par défaut des MR et la valeur de $CI_DEFAULT_BRANCH dans la CI. Pour la voir ou la changer: Settings > Repository > Branch defaults.