Branches de tâches & Merge Trains

Grosse feature, plusieurs personnes, stacks différentes ? Ne bourrez pas tout dans une seule branche feature/. Découpez en branches task/ courtes, faites des revues focalisées, puis assemblez le tout dans la branche parente feature/. Avec GitLab Ultimate, alignez les merges via des merge trains.

Pourquoi découper en branches de tâche

• Revues ciblées : diffs plus petits, plus cohérents
• Travail en parallèle : front et back avancent indépendamment
• Intégration plus propre : la branche de feature devient le point de ralliement pour l’assemblage et les tests

Exemple de flux

Ainsi, la PR finale vers main est plus courte et plus simple : on vérifie que l’intégration/le rebase s’est bien passé (devs contents), on merge une fonctionnalité complète testable de bout en bout (QA contente), et c’est publiable (PO content).

→

squash merge

Merge trains GitLab (optionnel)

• Ne laissez pas ça devenir le nouveau develop : la branche de feature doit rester petite et ne contenir qu’une fonctionnalité complète à la fois.
• Coordonnez les merges de vos task/ et finalisez‑les juste avant de merger la feature/ : mieux vaut résoudre les conflits séparément que rebaser un gros paquet en une fois.
• Avec GitLab Ultimate, faites dépendre la MR de feature/GG-1 des MRs des branches task/*, puis démarrez un merge train qui inclut l’ensemble des branches concernées. Les merges s’enchaînent dans un ordre sûr.

Repères

• Flux complet
• Politique squash‑then‑rebase