GitLab Stacked Merge Requests : empiler les merge requests plutôt que gonfler la même

Je viens de découvrir les stacked merge requests de GitLab (thks Claude Code 😂)

Le problème

Quand un travail avance vite – et il avance vite avec Claude Code – on a envie de faire plusieurs changements liés d’un coup. Ils finissent dans la même branche, et la MR arrive en revue avec des centaines de lignes qui mélangent trois ou quatre sujets. Personne ne relit ça sérieusement.

Ce que fait une pile

Au lieu d’une branche, on en ouvre plusieurs, presque unitaires, une par périmètre. Chaque MR cible non pas la branche par défaut mais la branche de la MR précédente. Seule celle du bas cible main.

Sur un travail récent, ça donne quatre MR, du bas vers le haut :

1. feat(stages) – l’étape d’entrée e0_prequalification et ses notes de préqualification, vers main ;
2. feat(candidates) – le owner, le membre du roster qui suit une candidature ;
3. feat(events) – l’annonce des mouvements d’entretien sur le bus ;
4. feat(slack) – la notification Slack au owner quand une candidature bouge.

GitLab affiche la pile dans l’en-tête de chaque MR (1 of 4) et rappelle la règle : le bas de la pile fusionne dans main en premier.

Ce que ça change à la revue

C’est là que la mécanique devient intéressante. Sans la pile, la quatrième MR aurait montré l’écart entre sa branche et main : tout le travail, quatre sujets empilés dans un seul diff. Avec la pile, elle ne montre que l’écart avec la branche juste en dessous – c’est-à-dire uniquement ce qu’elle ajoute.

Chaque MR répond donc à une seule question : qu’est-ce que cette étape apporte à la précédente ? Et la pile porte un ordre de lecture : on relit la première, on la fusionne, on passe à la suivante, qui vient poser sa couche par-dessus.

Un travail global reste condensé en un groupe de MR, mais chacune redevient relisable.