Résoudre les conflits de responsabilité lorsque des agents parallèles modifient le même artefact

Objectif

État au 25 octobre 2026. Rétablir une situation cohérente lorsque des agents parallèles ont modifié le même artefact à partir d’hypothèses incompatibles. Vérifier à nouveau la politique de fusion du dépôt, les exigences actuelles et l’isolation réelle des espaces de travail. Cette proposition prend pour point de départ un conflit de responsabilité ; elle ne constitue pas une introduction générale aux worktrees ni à la combinaison de résultats indépendants.

Prérequis

Identifier le responsable de l’intégration, la révision cible actuelle, les révisions candidates concurrentes et les exigences assignées à chaque contributeur. Préserver le travail local avant de modifier la cible. Les worktrees Git fournissent des arbres de travail et des index séparés tout en partageant les données du dépôt ; ne pas considérer un worktree comme une frontière de sécurité ni supposer que les ressources de build externes sont isolées.

Étapes

1. Figer les travaux en conflit. Empêcher les contributeurs concernés de modifier la cible partagée. Capturer chaque version candidate sous forme de commit immuable ou de patch conservé, y compris les modifications non commitées et les fichiers non suivis qui lui appartiennent. Consigner sa révision de base, l’objectif assigné, les chemins modifiés et les preuves de vérification. Ne laisser progresser les travaux sans rapport que s’ils ne peuvent pas modifier les données d’entrée contestées.
2. Désigner un responsable unique par artefact. Consigner qui peut accepter ou remplacer la version finale. Les autres agents peuvent proposer des corrections, mais l’intégration relève de ce responsable. Sérialiser la publication vers la cible et rejeter les soumissions se référant à une révision acceptée devenue obsolète. Le message d’achèvement d’un contributeur est une proposition, pas un transfert de responsabilité.
3. Qualifier le désaccord. Distinguer les chevauchements de texte des comportements incompatibles. Comparer les interfaces partagées, les valeurs de configuration par défaut, les dépendances, les sorties générées et leurs sources. Par exemple, un producteur qui renomme un champ et un consommateur qui conserve l’ancien nom nécessitent une mise en cohérence, même si leurs modifications portent sur des fichiers différents. Formuler explicitement l’exigence contestée avant de résoudre les conflits ligne par ligne.
4. Résoudre à partir des exigences et des preuves. Demander aux contributeurs la raison de chaque choix incompatible. Faire sélectionner ou construire par le responsable la version candidate qui respecte le contrat accepté, en consignant l’alternative rejetée et le motif du rejet. Régénérer les artefacts dérivés à partir de la source retenue lorsque le projet prévoit ce processus. Conserver un contrôle de non-régression ciblé sur le désaccord ; ne pas affaiblir les contrôles pour faire paraître compatibles les deux versions candidates.
5. Intégrer depuis un état récupérable. Utiliser un espace d’intégration propre, avec les commits de la version candidate et de la cible consignés. La documentation de fusion de Git avertit que l’abandon d’une fusion peut ne pas restaurer les modifications non commitées préexistantes. Examiner explicitement les conflits. Si --no-commit sert de pause pour inspection, tenir compte des fusions en avance rapide : Git indique qu’elles ne s’arrêtent pas à cette pause.
6. Vérifier l’artefact résolu et clore la question de la responsabilité. Exécuter git diff --name-only --diff-filter=U pour lister les entrées de fusion non résolues. Après résolution, utiliser git diff --check BASE, en remplaçant BASE par le commit cible initial consigné. Git diff recherche les marqueurs de conflit introduits et les erreurs d’espacement ; il ne garantit pas la correction du comportement. Exécuter les contrôles pertinents du projet sur la version candidate combinée, y compris sur l’interface contestée. Consigner le commit accepté et informer les contributeurs des versions candidates qu’il remplace.

Résultat attendu

Le conflit se termine par une décision dont le responsable est identifiable, une version candidate reproductible et une vérification liée à sa révision exacte. Les soumissions tardives nécessitent une nouvelle comparaison avec l’artefact accepté. Supprimer les espaces de travail temporaires après avoir confirmé la conservation du travail accepté et des preuves nécessaires.

Limites et base de vérification

Cette procédure n’a pas été mise à l’épreuve ici. La tester avec des modifications concurrentes sans risque, fusionnables sur le plan textuel mais en désaccord sur une interface. Une reprise réussie exige de détecter ce désaccord et d’écarter une nouvelle soumission devenue obsolète. La fusion du dépôt ne rapproche pas les actions externes déjà effectuées par les agents de leurs résultats réels ; celles-ci nécessitent un enregistrement de résultat distinct.