Comment utiliser Git worktrees avec des agents IA ?

Avec Git worktrees, je crée un espace isolé par agent IA, sans recloner le dépôt ni casser le contexte. C’est la bonne base quand plusieurs branches, urgences prod et assistants de code se télescopent. Le gain est simple : moins de conflits, plus de parallélisme.

Pourquoi les agents IA cassent le workflow Git ?

Les agents IA ne cassent pas Git parce qu’ils sont “dangereux”. Ils cassent le workflow parce qu’ils bossent souvent dans le même répertoire que vous, avec les mêmes fichiers, le même état local, les mêmes contraintes de branche. Et là, dès que la vraie vie arrive, ça coince.

Le cas classique, je le vois souvent. Vous lancez un agent sur une branche feature. Il modifie trois fichiers, il lance des tests, il commence à comprendre le contexte. Pendant ce temps, une urgence production tombe. Il faut revenir sur main, tirer la dernière version, corriger vite, pousser un hotfix.

Sur un workflow Git classique, ça veut dire quoi ? Ça veut dire que votre working directory devient une zone partagée entre vous, l’agent, et l’urgence du moment. Git vous bloque parce qu’il y a des fichiers modifiés. Vous faites un stash un peu forcé. Ou vous changez de branche et l’agent perd son contexte. Ou pire, vous laissez tourner l’agent pendant que vous bougez les fichiers sous ses pieds.

Les problèmes arrivent vite :

• Vous devez stasher du travail que vous n’avez pas vraiment relu.
• L’agent se retrouve interrompu au milieu d’une tâche.
• Le changement de branche modifie les fichiers qu’il était en train d’analyser.
• Votre correction prod et sa feature touchent les mêmes zones du code.
• Avec deux agents ou plus, chacun peut écraser ou réécrire une partie du travail de l’autre sans le vouloir.

Ce n’est pas dramatique, mais c’est fragile. Et surtout, ce n’est pas un problème d’IA. Le vrai sujet, c’est l’absence d’isolation au niveau du workspace. Un workspace, c’est simplement le dossier de travail dans lequel les fichiers du dépôt existent réellement sur votre machine. Si un développeur, un agent IA et une urgence prod partagent ce même dossier, Git devient un point de friction.

Chez des équipes que j’accompagne, le sujet arrive très vite dès qu’on met deux agents ou plus sur le même dépôt. Au début, ça semble pratique. Puis on passe son temps à vérifier qui a modifié quoi, sur quelle branche, avec quel contexte.

La bonne direction, ce n’est pas de dupliquer les dépôts partout ni de ralentir l’usage de l’IA. C’est de garder le même dépôt Git, mais de séparer les espaces de travail. C’est exactement là que les Git worktrees deviennent intéressants.

C’est quoi un Git worktree ?

Un Git worktree, c’est un répertoire de travail séparé, relié au même dépôt Git, avec sa propre branche, son propre index et son propre état de fichiers. Dit plus simplement, c’est un autre dossier de votre projet, mais sans refaire une copie complète du dépôt.

J’aime bien voir ça comme plusieurs bureaux reliés à la même archive Git. L’archive, c’est l’historique du projet, les commits, les objets Git. Elle est partagée. Chaque bureau, lui, garde ses fichiers ouverts, ses changements en cours, sa branche active. Vous pouvez bosser sur une feature dans un dossier, corriger un bug urgent dans un autre, et laisser un agent IA travailler dans un troisième sans tout mélanger.

Le point important, surtout avec des agents IA, c’est l’isolation. Un agent lancé dans un worktree ne voit pas les modifications non commitées d’un autre worktree. Il ne touche pas ses fichiers. Il ne dépend pas non plus de son changement de branche. Si vous passez de main à feature/test dans votre dossier principal, le worktree de l’agent reste sur sa branche à lui.

Chaque worktree a donc son propre espace de travail Git :

• Son propre working tree, c’est-à-dire les fichiers visibles dans le dossier.
• Son propre index, c’est-à-dire la zone de staging où Git prépare le prochain commit.
• Sa propre branche, dans la plupart des usages, ce qui évite les conflits de contexte.

Ce n’est pas magique, mais c’est très pratique. Chez un client, on avait plusieurs agents qui modifiaient des parties différentes d’un même repo. Sans worktrees, c’était vite sale. Avec worktrees, chaque agent avait son bureau, et nous on gardait la main sur ce qui était fusionné ou jeté.

Élément	Ce qui est partagé	Ce qui est isolé
Historique Git	Les commits et les objets du dépôt	Rien, tout le monde lit la même archive
Branche	Le dépôt connaît toutes les branches	Chaque worktree peut pointer vers sa branche
Fichiers de travail	Le contenu suivi vient du même dépôt	Les modifications locales restent dans chaque dossier
Index Git	Le mécanisme Git est le même	Chaque worktree a son propre staging

Pourquoi c’est mieux que plusieurs clones ?

Git worktrees est mieux que plusieurs clones parce qu’on évite de dupliquer l’historique Git tout en gardant des espaces de travail séparés. C’est le vrai sujet. Pas une astuce magique, juste une manière plus propre de travailler quand on a plusieurs branches actives, surtout avec des agents IA qui modifient du code en parallèle.

La solution naïve, je l’ai vue partout, et je l’ai utilisée aussi : on clone le même dépôt plusieurs fois. Un dossier pour une feature, un dossier pour un bug urgent, un dossier pour tester un agent IA sans casser le reste. Au début, ça marche très bien. C’est simple à comprendre. Chaque dossier est indépendant, donc on se sent en sécurité.

Le problème arrive quand ça grossit. Chaque clone embarque son propre dossier Git, avec son historique, ses objets, ses références. Les objets Git, ce sont les données internes que Git stocke pour représenter les commits, les fichiers, les branches. Résultat : l’espace disque est multiplié. Sur un petit projet, on s’en fiche. Sur un monorepo ou un projet avec beaucoup d’historique, ça devient vite absurde.

Autre truc pénible : les clones ne partagent pas vraiment leur état local. Un commit fait dans un clone n’apparaît pas immédiatement dans l’autre. Il faut pousser, tirer, ajouter des remotes locales parfois, bref on rajoute de la plomberie. Avec plusieurs agents IA, ça devient vite lourd. Chaque agent a son dépôt, ses branches, son état, ses dépendances parfois, et vous passez plus de temps à synchroniser qu’à relire le code produit.

Avec Git worktrees, je garde le bon compromis. Chaque agent IA a son propre dossier de travail, donc ses fichiers isolés. Un agent peut bosser sur une branche feature, un autre sur un hotfix, un troisième sur une expérimentation. Mais tout reste rattaché au même dépôt Git. L’historique est partagé, les objets Git ne sont pas dupliqués, et je garde une vue locale plus cohérente.

Ça ne remplace pas les bonnes pratiques Git. Il faut toujours faire des commits propres, nommer les branches correctement, relire le code, synchroniser avec l’équipe. Les worktrees règlent surtout un problème précis : l’isolation locale du travail sans multiplier les clones.

Critère	Clones multiples	Git worktree
Espace disque	Dupliqué pour chaque clone	Historique partagé, moins de duplication
Historique Git	Séparé dans chaque dossier	Commun au même dépôt
Isolation des fichiers	Oui, chaque clone a son dossier	Oui, chaque worktree a son dossier
Usage avec agents IA	Fonctionne, mais devient lourd à gérer	Plus propre pour lancer plusieurs agents sur plusieurs branches

Quelles commandes Git worktree utiliser ?

Quelques commandes suffisent pour garder un workflow Git worktrees propre avec des agents IA. Je garde surtout une idée en tête : git worktree add est la commande centrale. Les autres servent à surveiller, protéger et nettoyer.

Pour créer un worktree avec une nouvelle branche dédiée à une tâche, par exemple une feature d’authentification, j’utilise cette commande.

git worktree add ../monapp-feat-auth -b feat/auth

Ça crée un nouveau dossier à côté du dépôt principal, avec sa propre branche. C’est typiquement ce que je donne à un agent IA pour bosser sans toucher à mon espace principal.

Pour créer un espace sur une branche existante, si le contexte s’y prête, par exemple depuis main, j’utilise ça.

git worktree add ../monapp-hotfix main

Je le fais plutôt pour lire, tester, ou corriger vite. Attention quand même, si deux espaces travaillent sur la même branche, on peut vite se marcher dessus.

Pour voir les worktrees actifs, je lance simplement cette commande.

git worktree list

C’est la commande de contrôle. Elle montre les dossiers, les branches associées, et les commits. Très utile quand plusieurs agents tournent en parallèle.

Pour éviter une suppression accidentelle d’un worktree important, je peux le verrouiller.

git worktree lock

Je m’en sers quand un agent est encore en train de travailler, ou quand je veux éviter qu’un script de nettoyage fasse n’importe quoi.

Pour le réactiver, je le déverrouille avec cette commande.

git worktree unlock

Une fois le travail terminé, mergé ou abandonné, je supprime le dossier du worktree comme ça.

git worktree remove ../monapp-feat-auth

Git nettoie correctement le lien avec le dépôt principal. C’est mieux qu’un simple rm -rf, surtout quand on veut éviter des références fantômes.

Pour nettoyer les références obsolètes, par exemple après des suppressions manuelles ou des dossiers disparus, je lance cette commande.

git worktree prune

Le vrai piège, ce n’est pas Git. C’est le nommage. Je garde une convention lisible pour les dossiers et les branches, du genre monapp-feat-auth avec feat/auth. Sinon on ne résout rien, on déplace juste le désordre ailleurs.

Comment démarrer proprement avec Git worktrees ?

Pour démarrer proprement avec Git worktrees, je pars toujours d’une branche principale propre. C’est bête, mais c’est là que beaucoup de problèmes commencent. Un worktree, c’est un deuxième dossier de travail relié au même dépôt Git. Si le dépôt de départ est déjà sale, avec des fichiers modifiés partout, on ne crée pas un workflow parallèle, on duplique juste le bazar.

Premier prérequis : il faut Git 2.5 minimum. C’est la version qui a introduit git worktree. Si vous êtes sur une machine un peu ancienne, je vérifie avant de partir trop loin.

git --version

Ensuite, mon réflexe, c’est de regarder l’état réel du dépôt. Pas ce que je pense avoir fait. Ce que Git voit.

git status

Si j’ai du travail en cours que je veux garder, je le commit avant de créer le worktree. Même un commit temporaire propre vaut mieux qu’un dépôt flou. J’ai déjà vu un agent IA modifier des fichiers qui étaient déjà à moitié changés par un humain, et franchement, c’est le genre de mélange qu’on évite une fois qu’on s’est fait avoir.

git add .
git commit -m "préparation worktree"

Si je veux juste mettre mes changements de côté sans les garder dans l’historique, je fais un stash. Le stash, c’est une pile temporaire où Git range vos modifications pour revenir à un état propre.

git stash

Une fois que le dépôt est propre, je crée un worktree dédié à la tâche. Ici, je crée un dossier voisin et une branche claire pour une fonctionnalité d’authentification.

git worktree add ../monapp-feat-auth -b feat/auth

Avec un agent IA, je fais simple : j’ouvre uniquement ce dossier dans mon éditeur ou mon outil IA. Je lance l’agent dans ce répertoire, pas à la racine du dépôt principal. Comme ça, l’agent travaille dans son bac à sable, sur sa branche, avec son contexte. Si j’ai une urgence ou un hotfix, je crée un autre worktree. Je ne mélange pas deux agents dans le même dossier, sinon on perd vite la trace de qui a modifié quoi.

Ma checklist de départ reste courte :

• Dépôt propre.
• Branche claire.
• Dossier nommé selon la tâche.
• Un agent par worktree.
• Nettoyage après merge.

Et si votre vrai problème IA était juste l’isolation ?

Git worktrees ne rend pas le développement assisté par IA parfait, mais ça enlève une grosse source de friction. Je garde le même dépôt, le même historique Git, et je donne à chaque agent son propre espace de travail. Plus besoin de jongler avec des clones partout, de casser le contexte d’un agent parce qu’une urgence prod arrive, ou de risquer des collisions bêtes entre branches. Le bon réflexe, c’est simple : un sujet, une branche, un worktree. Pour vous, le bénéfice est très concret : un workflow IA plus propre, plus rapide, et beaucoup moins fragile.

FAQ

• À quoi sert Git worktree avec des agents IA ?
  Git worktree sert à donner un espace de travail séparé à chaque agent IA. Chaque agent peut travailler sur sa branche, dans son dossier, sans être perturbé par les changements de branche ou les fichiers modifiés ailleurs.
• Quelle est la différence entre Git worktree et un clone Git ?
  Un clone duplique le dépôt. Un worktree partage le même historique Git et les mêmes objets, tout en créant un répertoire de travail séparé. C’est plus léger et plus pratique quand on travaille sur plusieurs branches en parallèle.
• Est-ce qu’un agent IA peut modifier les fichiers d’un autre worktree ?
  Non, tant que l’agent travaille bien dans son propre répertoire. Chaque worktree a son propre état de fichiers et son propre index. C’est justement l’intérêt : isoler le contexte local de chaque agent.
• Quelle version de Git faut-il pour utiliser les worktrees ?
  Il faut Git 2.5 minimum. Avant de démarrer, je vérifie aussi que ma branche principale est propre avec git status, puis je commit ou je stash ce qui doit l’être.
• Quelles commandes Git worktree faut-il connaître ?
  Les commandes utiles sont surtout git worktree add pour créer un worktree, git worktree list pour les voir, git worktree lock et unlock pour les protéger, git worktree remove pour les supprimer, et git worktree prune pour nettoyer les références obsolètes.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent industrialiser leurs workflows data, IA et automatisation sans transformer leur stack en usine à gaz. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos usages IA, vos automatisations ou vos workflows techniques, contactez-moi.