Plusieurs agents sur un projet : travailler avec Git worktree
Neaptide · 20 septembre 2026 · 8 min de lecture
Séparez les tâches d'agents avec Git worktree : dossiers, branches, environnements, vérification et intégration.
Dans cet article
Le travail parallèle se complique lorsque deux agents modifient le même dossier. L'un corrige un formulaire, l'autre réorganise un composant, et les tests portent sur un mélange de changements inachevés. Git worktree sépare les fichiers : chaque tâche dispose de son dossier et de sa branche.
Un worktree est une copie de travail supplémentaire du même dépôt Git. L'historique est partagé, mais la branche extraite et les fichiers de travail sont distincts. On peut ainsi développer plusieurs modifications en même temps. 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, convenez d'abord de l'interface et traitez la dépendance dans l'ordre.
| 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 |
Les dossiers séparés évitent de mélanger les fichiers inachevés, mais ne règlent pas les contradictions fonctionnelles. Deux changements peuvent fusionner sans conflit Git et pourtant casser l'application ensemble.
Créer deux copies de travail
L'exemple suppose un dépôt existant contenant au moins un commit. Exécutez les commandes depuis son dossier principal. Les noms de branches et des dossiers voisins doivent être libres.
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 sont pas transférées. Si elles sont nécessaires aux deux tâches, préparez d'abord une version de départ convenue. Ne commitez pas le travail inachevé d'un collègue 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 propose aussi son propre lancement en worktree, décrit dans le guide des sessions parallèles. La méthode manuelle rend les dossiers et les branches visibles indépendamment du 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 au second la documentation, en précisant de laisser le code du formulaire intact. Ce sont des exemples pédagogiques : adaptez chemins, commandes et critères à votre projet.
Vérifiez l'environnement de chaque copie. Les dépendances et fichiers de configuration personnels peuvent demander une préparation distincte. Deux serveurs de développement doivent utiliser des ports différents. S'ils partagent une base de test, isolez leurs données ou évitez les scénarios concurrents qui la modifient.
Accepter le résultat
Examinez chaque diff séparément. Vérifiez d'abord le respect de la consigne, puis les tests. Enregistrez les changements validés dans des commits sur leurs branches respectives.
Fusionnez les branches l'une après l'autre dans la branche d'intégration choisie. Après la seconde fusion, vérifiez de nouveau le parcours utilisateur commun. Des tests réussis sur deux branches séparées ne prouvent pas leur bon fonctionnement conjoint.
En cas de conflit, déterminez le comportement à préserver. Accepter mécaniquement toutes les modifications d'un côté peut supprimer 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 option de forçage, Git refuse de supprimer un worktree ordinaire comportant des changements non commités. N'ajoutez pas `--force` pour faire disparaître l'erreur. Les branches restent après la suppression des copies ; gérez-les séparément. Commandes worktree.