Stacked MRs : chaîner des MR dépendantes

Le problème : des changements qui dépendent l'un de l'autre

Certaines évolutions se découpent naturellement en étapes ordonnées qui touchent les mêmes fichiers — par exemple, renommer un rôle PostgreSQL puis basculer la RLS qui l'utilise. Deux mauvaises options :

• une seule méga-MR : diff énorme, illisible, revue bâclée — l'inverse de ce qu'une équipe (et des agents) produisant beaucoup de petits changements devrait viser ;
• deux MR indépendantes vers main : la seconde ne compile pas sans la première, les conflits sont garantis, la CI de la seconde est rouge tant que la première n'est pas mergée.

La bonne réponse est une chaîne de MR (stacked MRs) : chaque MR est petite, autonome à relire, et construite au-dessus de la précédente.

Le mécanisme

main
 └── MR1  (feature/rename-role)        → cible: main
      └── MR2  (feature/rls-switch)     → cible: feature/rename-role   ← PAS main
           └── MR3 (feature/cleanup)    → cible: feature/rls-switch

• MR2 cible la branche de MR1, pas main. Son diff n'affiche donc que ses changements à elle (pas ceux de MR1) → relecture nette.
• On revoit et on merge dans l'ordre : MR1 → MR2 → MR3.
• Retarget après merge : dès que MR1 est mergée dans main, on repointe MR2 sur main (la plupart des forges — GitLab, GitHub — le font automatiquement ou en un clic). MR2 devient alors une MR normale, avec un diff propre.

Deux disciplines qui gardent la chaîne saine :

1. rebaser la pile vers le bas : si MR1 change pendant la revue, rebaser MR2 (puis MR3) dessus pour que les diffs restent exacts ;
2. une MR = une intention : le rename dans l'une, le switch RLS dans l'autre — jamais mélangés, même s'ils partent ensemble.

Pourquoi c'est clé quand des agents contribuent

Un agent en CI (leçon précédente) produit des MR petites et fréquentes. Empiler naïvement les dépendances re-crée la méga-MR qu'on voulait éviter. Les stacked MRs laissent humains et agents livrer par incréments revus un par un, sans bloquer la file : chaque maillon passe la CI et la revue isolément, dans l'ordre.

Le but n'est pas de livrer moins souvent parce que « c'est lié » — c'est de garder chaque diff à la taille d'une revue sérieuse, en rendant la dépendance explicite (la branche cible) plutôt que subie (un gros diff ou une CI rouge).