Git worktrees pour les agents de code IA : une méthode sûre.
Un Git worktree donne à chaque tâche ses propres fichiers extraits et sa branche courante, tout en partageant les objets et les références du dépôt. Vous pouvez ainsi comparer des tentatives parallèles sans faire modifier le même dossier par plusieurs agents.
Réponse courte
Attribuez à chaque tentative un worktree lié, une branche et une tâche limitée. Démarrez les deux depuis le même commit de base enregistré, lancez Codex, Claude Code, OpenCode, Cursor ou un autre outil capable de travailler dans un dossier, et gardez le checkout principal pour la revue. Exigez des résultats commités et examinables avant de les comparer.
Choisissez le résultat conforme aux critères, mettez les processus d’écriture en pause, vérifiez que le checkout cible est propre, puis fusionnez via la revue et les tests habituels. Les worktrees réduisent les collisions de fichiers, mais ne sont pas des sandboxes : objets, la plupart des refs et remotes sont partagés, et les accès accordés au shell restent disponibles.
1. Créez un worktree propre par tentative
Commencez dans le checkout principal. Vérifiez qu’il est propre, mettez à jour ou inspectez la base voulue, enregistrez ce commit une fois, puis créez les deux branches depuis cette base.
git status --short
git branch --show-current
BASE_COMMIT=$(git rev-parse HEAD)
git worktree add -b agent/task-a ../agent-task-a "$BASE_COMMIT"
git worktree add -b agent/task-b ../agent-task-b "$BASE_COMMIT"
git worktree listAssociez chaque outil à son dossier et à sa branche. N’utilisez pas la même branche dans deux worktrees et ne laissez pas la tâche A écrire dans le dossier B. La base enregistrée rend la comparaison reproductible même si la branche distante avance.
Un dossier séparé ne limite pas l’autorité du shell. Réduisez les identifiants et permissions de l’hôte au strict nécessaire et imposez une approbation distincte aux écritures Git qui exigent un contrôle humain.
2. Donnez les mêmes critères d’acceptation
Donnez aux deux tentatives la même tâche, les mêmes tests, contraintes et base. Demandez à chaque agent d’éviter les modifications hors sujet et de commiter son résultat sur sa branche. Un arbre non commité est plus difficile à comparer et plus facile à perdre au nettoyage.
Mettez les agents en pause avant la revue. Le worktree sépare les fichiers extraits, mais un processus largement autorisé peut encore modifier des refs partagées, joindre des remotes ou accéder à des fichiers hors de son dossier.
3. Comparez depuis la base enregistrée
Vérifiez l’état des deux dossiers, puis comparez chaque branche avec le même commit de base. Gardez cette base fixe pour les historiques et les diffs.
git -C ../agent-task-a status --short
git -C ../agent-task-b status --short
git log --oneline "$BASE_COMMIT"..agent/task-a
git log --oneline "$BASE_COMMIT"..agent/task-b
git diff "$BASE_COMMIT" agent/task-a
git diff "$BASE_COMMIT" agent/task-bExaminez le comportement, les tests, les fichiers modifiés et la portée. Terminer ne suffit pas pour fusionner. Préférez la tentative qui satisfait les critères avec le changement le plus petit et le plus clair.
Ne fusionnez pas les deux tentatives par défaut. Si les bonnes idées sont réparties, sélectionnez un commit vérifié ou préparez une branche combinée propre, puis examinez ce nouveau résultat séparément.
4. Fusionnez le résultat choisi par le contrôle habituel
Revenez au checkout principal propre, sélectionnez une branche revue et utilisez le chemin habituel de fusion non fast-forward.
CHOSEN_BRANCH=agent/task-a
git status --short
git diff "$BASE_COMMIT" "$CHOSEN_BRANCH"
git merge --no-ff "$CHOSEN_BRANCH"Gardez les agents en pause pendant la fusion. Arrêtez-vous au moindre conflit, inspectez-le et résolvez-le par le processus normal ; le workflow worktree ne doit pas rendre ce choix automatique.
Exécutez les tests du dépôt après la fusion et avant tout push. Les worktrees ne remplacent ni revue, ni CI, ni protection de branche, ni approbation humaine, et n’empêchent pas un shell autorisé séparément de pousser.
5. Nettoyez sans forcer
Inspectez les deux dossiers et préservez tout changement utile avant de supprimer un checkout lié.
git -C ../agent-task-a status --short
git -C ../agent-task-b status --short
git worktree remove ../agent-task-a
git worktree remove ../agent-task-b
git worktree list
git worktree prune --dry-runSupprimez un worktree sans forcer seulement s’il est propre ou si le travail restant a été abandonné délibérément. Gardez les branches jusqu’à la fin de la revue ; supprimer un dossier et supprimer une branche sont deux décisions.
Prévisualisez l’élagage avant de modifier les entrées administratives. La simulation montre les entrées obsolètes sans les supprimer. Si Git refuse la suppression normale, examinez les changements ou verrous plutôt que de contourner la protection.
Ce que les worktrees séparent et partagent encore
| Séparé par worktree | Partagé ou toujours accessible |
|---|---|
| Fichiers extraits, changements locaux et artefacts de build | Objets du dépôt et la plupart des refs |
| Branche courante et état HEAD/index propre au worktree | Remotes, identifiants et configuration partagée |
| Dossier de tâche utilisé par l’outil | Tout ce qu’un shell largement autorisé peut atteindre ailleurs |
Utilisez les worktrees pour paralléliser les fichiers, clarifier les diffs et répéter les comparaisons. Utilisez permissions, branches protégées, revue et approbations pour gouverner l’autorité.
La compatibilité dépend de la capacité de l’outil à travailler dans un dossier choisi et à respecter la limite de tâche. Ce flux convient à ces outils ; il ne prouve pas que tous offrent les mêmes contrôles.
Sources Git officielles
Comparez les tentatives parallèles sans perdre le contrôle de la revue.
FluxGit peut afficher les worktrees liés et l’état du dépôt, comparer les changements et soumettre les propositions Git des agents compatibles à une approbation sur ordinateur. Un shell séparé conserve les accès accordés par son hôte.