← Tous les articles

Tickets parallèles : que garantissent les tests et les worktrees ?

Deux tickets verts peuvent encore se contredire

Un conflit textuel signifie que Git ne peut pas combiner des modifications. Un conflit sémantique signifie que les comportements demandés sont incompatibles, même si le rebase réussit et les tests passent. Les worktrees isolent les fichiers de travail ; ils ne prouvent pas la compatibilité des intentions.

Exemple : le ticket A exige qu’une remise soit refusée aux comptes gratuits ; le ticket B exige qu’elle soit disponible pour tous. Leurs tests peuvent rester verts s’ils couvrent des parcours différents. Il faut expliciter la règle commune et tester le même cas, pas seulement résoudre le diff.

Préqualifier et ordonner les travaux liés

La préqualification examine les tickets actifs et peut identifier des dépendances fonctionnelles. Lorsqu’un chevauchement exige un ordre, A devient un prérequis de B : B attend la fin et l’intégration de A avant de travailler sur la base qui contient son résultat. Modifier le même fichier ne suffit pas, à lui seul, à imposer cette dépendance.

Une demande trop large peut être découpée en tickets enfants. Les travaux indépendants avancent en parallèle ; les dépendances ordonnent les autres. Le parent vérifie ensuite le résultat d’ensemble. Cette analyse réduit les collisions, mais ne garantit pas que toute contradiction métier sera détectée.

Vérifier la version intégrée

L’agent commite dans son worktree avec les hooks du projet activés. La file d’intégration sérialise les tickets d’un même projet ; les commits sont rebasés sur la dernière branche de base. Si cette base a avancé, l’agent doit rejouer les tests concernés et les contrôles du projet, puis examiner les tests ajoutés ou modifiés par les autres tickets. Un rebase propre ne suffit pas.

Les hooks n’exécutent que les contrôles configurés : un hook de formatage ne valide pas une règle métier. Les tests d’intégration et de bout en bout doivent couvrir les interactions entre fonctionnalités, en complément des tests unitaires.

Ce qui reste à arbitrer

Des tests verts ne garantissent pas l’absence de conflit sémantique. Une attente absente des tests peut passer inaperçue. Si deux demandes se contredisent, il faut clarifier les critères d’acceptation et choisir la règle attendue avant l’intégration ; la revue humaine reste utile pour cet arbitrage. Désactiver la fusion automatique permet de garder le résultat dans l’onglet Revue.

Pour préparer un ticket : nommez la fonction partagée, indiquez les tickets liés, écrivez la règle commune et un exemple de non-régression. Le nombre de messages par ticket n’est pas une garantie de qualité ni une promesse de suppression de toute revue.

Consultez le guide des worktrees et de l’intégration, la documentation de l’orchestration et l’article sur les dépendances et tickets parents.