Plusieurs agents sur un projet : travailler avec Git worktree
Neaptide · 20 septembre 2026 · 8 min de lecture · Mis à jour: 3 octobre 2026
Séparez les tâches d'agents avec Git worktree : dossiers, branches, environnements, vérification et intégration.
Dans cet article
Deux agents qui modifient le même dossier de travail se gênent. L'un corrige un formulaire, l'autre réorganise un composant, et les tests tournent sur un mélange de changements inachevés. Git worktree sépare les fichiers en donnant à chaque tâche son dossier et sa branche.
Un worktree est une copie de travail supplémentaire du même dépôt Git. L'historique est commun, mais chaque copie a sa branche extraite et ses fichiers de travail, si bien qu'on peut mener plusieurs modifications de front. Le manuel Git décrit ce fonctionnement et les commandes.
Quelles tâches mener en parallèle ?
Commencez par deux changements indépendants : corriger la gestion des erreurs d'un formulaire et mettre à jour un texte d'aide. Si les deux tâches touchent un schéma de données ou un composant commun, fixez d'abord l'interface, puis traitez la partie dépendante en séquence.
| Tâches qui se prêtent à la séparation | Ordre à définir au préalable |
|---|---|
| Correction du formulaire et documentation | Modification d'API et interface qui en dépend |
| Tests de modules indépendants | Deux refactorisations du même composant |
| Recherche d'un bug et correction de texte distincte | Migration des données et code du nouveau schéma |
Des dossiers séparés empêchent les fichiers inachevés de se mélanger. Ils ne règlent pas les contradictions fonctionnelles : deux changements peuvent fusionner sans le moindre conflit Git et casser l'application une fois réunis.
Créer deux copies de travail
L'exemple suppose un dépôt qui contient déjà au moins un commit. Exécutez les commandes depuis son dossier principal. Aucune branche ni aucun dossier voisin ne doit déjà porter ces noms.
git status --short
git worktree add -b ai/form-fix ../project-form HEAD
git worktree add -b ai/docs-update ../project-docs HEAD
git worktree listLes deux copies partent du commit HEAD actuel. Les modifications non commitées du dossier d'origine ne suivent pas. Si les deux tâches en ont besoin, préparez d'abord une version de départ convenue. Ne commitez pas le travail inachevé d'un collègue juste pour suivre cet exemple.
Dans deux terminaux distincts, ouvrez les nouveaux dossiers et lancez l'agent. Pour Claude Code :
cd ../project-form
claudeOuvrez `../project-docs` dans le second terminal. Claude Code sait aussi créer la copie lui-même : `claude --worktree <nom>` la place dans `.claude/worktrees/`, à l'intérieur du dépôt. Le guide des sessions parallèles donne le détail. La méthode manuelle garde un avantage : dossiers et branches restent visibles quel que soit le client.
Donner une consigne à chaque agent
Définissez le résultat et le périmètre. Par exemple, pour le premier agent :
Corrige le message d'erreur d'envoi du formulaire dans le worktree actuel. Retrouve le formulaire et ses tests, et préserve l'envoi réussi. Ne modifie ni la structure de l'API ni la documentation. Présente le diff et les résultats des vérifications. Ne fusionne pas les branches.Confiez la documentation au second, en précisant qu'il ne doit pas toucher au code du formulaire. Ces consignes sont des exemples : reprenez les chemins, les commandes et les critères de votre projet.
Vérifiez l'environnement de chaque copie. Il faudra sans doute réinstaller les dépendances et recopier à la main les fichiers de configuration personnels que Git ne suit pas (`.env`, par exemple). Deux serveurs de développement doivent écouter sur des ports différents. S'ils partagent une base de test, isolez leurs données ou évitez de lancer en même temps les scénarios qui la modifient.
Accepter le résultat
Examinez chaque diff séparément. Comparez-le d'abord à la consigne, regardez ensuite les tests. Commitez les changements validés, chacun sur sa branche.
Fusionnez les branches l'une après l'autre dans la branche d'intégration choisie. Après la seconde fusion, refaites le parcours utilisateur complet : des tests au vert sur deux branches séparées ne disent rien de leur comportement une fois réunies.
En cas de conflit, décidez d'abord quel comportement doit rester. Ne demandez pas à l'agent d'accepter mécaniquement toutes les modifications d'un côté, il risque d'effacer une partie de l'autre tâche.
Supprimer un worktree terminé
Assurez-vous que les changements utiles sont enregistrés et acceptés, et qu'aucun fichier non sauvegardé ne reste. Depuis la copie principale :
git worktree remove ../project-form
git worktree remove ../project-docsSans `--force`, Git refuse de supprimer un worktree qui contient encore des changements non commités ou des fichiers non suivis. N'ajoutez pas l'option dans le seul but de faire disparaître l'erreur. Les branches survivent à la suppression des copies. Leur sort se décide à part.