Deux branches terminées, deux suites de tests vertes, une seule question : laquelle merger en premier ? La réponse la plus commune consiste à respecter l’ordre d’ouverture des tickets, ou pire, l’ordre alphabétique des noms de branche. Ce choix ignore une information pourtant disponible dès que la CI tourne : ce que chaque suite de tests révèle sur la nature du changement.
Cet article ne traite pas de la stratégie Git à adopter (trunk-based, Git Flow ou autre) : le sujet ici est uniquement le critère de décision, une fois que deux branches sont mûres et candidates à la fusion.
Le mauvais réflexe : se fier à l’ordre chronologique
Fusionner dans l’ordre où les développements ont commencé semble équitable. C’est aussi arbitraire que de trier des dossiers médicaux par date de dépôt plutôt que par gravité. Une branche ouverte il y a trois semaines qui ne touche qu’un fichier de configuration n’a pas le même poids qu’une branche ouverte hier qui modifie une fonction appelée par quarante tests.
Le critère chronologique a un seul mérite : il est simple à appliquer sans réfléchir. C’est précisément ce qui le rend dangereux dès que deux branches touchent des zones voisines du code.
Le critère qui fonctionne : la surface de tests touchée
Avant de fusionner, il est possible d’observer, pour chaque branche, la liste des tests que la CI a exécutés et marqués comme concernés (via un test runner qui journalise les tests exécutés, ou simplement en comparant les fichiers modifiés aux fichiers de tests qui les couvrent). Trois indicateurs se dégagent :
- Le nombre de tests qui échoueraient si la branche était retirée (autrement dit, la couverture réelle du changement).
- Le nombre de fichiers de tests partagés que la branche modifie (fixtures, factories, helpers communs).
- La présence ou non de tests nouvellement ajoutés qui verrouillent un comportement critique (paiement, authentification, envoi d’e-mail).
La règle pratique tient en une phrase : la branche qui touche le risque le plus élevé, mesuré par ce que ses tests couvrent, passe en premier. Une fusion tardive d’un correctif critique augmente la fenêtre pendant laquelle le bug reste en production ; une fusion précoce d’un changement cosmétique ne coûte rien à retarder.
Le piège des fixtures partagées
Une branche qui modifie une factory de test utilisée par plusieurs classes (par exemple la structure d’un objet renvoyé par self::factory()->post->create() dans un projet WordPress) doit presque toujours passer en dernier, quelle que soit sa date d’ouverture. La raison est mécanique : toute branche fusionnée après elle devra rebaser ses propres tests sur la nouvelle fixture, ce qui multiplie les conflits de merge sur des fichiers de test plutôt que sur du code métier.
Concrètement, avant de décider un ordre, il vaut la peine de se poser une question simple : « si je fusionne A puis B, est-ce que B doit être réécrite ? » Si la réponse est oui, B passe en premier, indépendamment de tout autre critère.
Durée d’exécution : un faux critère
Certaines équipes préfèrent fusionner d’abord la branche dont la suite de tests s’exécute le plus vite, pour « libérer la file » plus rapidement. C’est une optimisation de flux qui ignore le risque. Une suite rapide qui teste un module périphérique ne devrait jamais passer devant une suite plus longue qui verrouille un parcours de paiement, même si cela retarde légèrement le tableau de bord de la CI.
La vitesse d’exécution reste un signal utile, mais pour une décision différente : optimiser l’ordre dans lequel les branches sont testées en parallèle, pas l’ordre dans lequel elles sont fusionnées.
Un exemple de grille de décision
| Signal observé dans la suite de tests | Effet sur la priorité de fusion |
|---|---|
| Nouveaux tests sur un parcours critique | Fusion en priorité |
| Modification d’une fixture ou factory partagée | Fusion en dernier |
| Aucun test nouveau, code périphérique | Peut attendre sans risque |
| Suite de tests très longue mais faible risque | N’accélère pas la priorité |
La question à se poser avant chaque fusion n’est pas « qui attend depuis le plus longtemps », mais « qu’est-ce que je perds si ce changement reste en attente une heure de plus ». Les tests donnent la réponse la plus honnête à cette question.
En résumé
Choisir l’ordre de fusion de deux branches à partir de ce que révèlent leurs tests évite deux écueils classiques : retarder un correctif critique au profit d’un changement cosmétique arrivé plus tôt, et générer des conflits de fixtures évitables en fusionnant dans le mauvais sens. Le critère tient en une question simple, reproductible à chaque nouvelle paire de branches en attente, sans avoir besoin d’outillage supplémentaire.
