Git worktrees IA comment éviter les conflits ?

Les git worktrees isolent chaque agent IA dans son propre dossier, sans dupliquer le dépôt. Je m’en sers pour éviter les collisions, garder le contexte d’une tâche, lancer un hotfix sans casser le travail en cours, et revenir proprement sur chaque branche.

C’est quoi un git worktree ?

Un git worktree est un répertoire de travail séparé, rattaché au même dépôt Git, qui permet d’avoir plusieurs branches ouvertes en même temps sans faire plusieurs clones. C’est vraiment ça l’idée. Vous gardez un seul dépôt Git, mais vous pouvez avoir plusieurs dossiers sur votre machine, chacun positionné sur une branche différente.

Git partage le même historique et les mêmes objets entre ces worktrees. Les objets, c’est simplement ce que Git stocke en interne pour représenter les commits, les fichiers, les branches. Donc on ne duplique pas tout comme avec plusieurs clones. Par contre, chaque worktree a son propre état de travail, son propre index, et ses propres fichiers checkoutés. L’index, c’est la zone intermédiaire de Git, celle où les fichiers passent quand vous faites un git add avant un commit.

Le point vraiment utile avec l’IA, il est là. Un agent IA qui travaille dans un worktree ne voit pas et ne modifie pas les fichiers non commités d’un autre worktree. Il peut casser des fichiers dans son dossier, tenter une refacto, générer du code un peu trop ambitieux, pendant que votre autre dossier reste propre. J’ai vu ça chez un client avec plusieurs agents lancés en parallèle, et franchement, sans séparation claire, ça devient vite ingérable.

Git worktree existe depuis Git 2.5. Donc ce n’est pas une astuce récente, fragile, ou un hack trouvé dans un coin de Stack Overflow. Ce qui change aujourd’hui, c’est son intérêt avec les agents IA. Avant, on l’utilisait surtout pour jongler entre deux branches. Maintenant, on peut laisser plusieurs agents travailler en parallèle sans qu’ils se marchent dessus.

Un exemple simple. Je lance un agent IA sur une branche feat/auth pour refaire l’authentification. Il modifie plusieurs fichiers, il ajoute des tests, il est au milieu d’un truc pas encore stable. Puis un bug critique arrive en production.

• Sans worktree, je dois faire un stash, changer de branche, traiter le bug, revenir, récupérer mon stash, et espérer ne rien oublier.
• Avec worktree, j’ouvre un autre dossier sur une branche hotfix/login-crash, je corrige le bug, et le travail de l’agent sur feat/auth reste intact dans son dossier.

C’est simple, mais ça change beaucoup de choses. Surtout quand vous commencez à confier du code à des agents IA qui vont vite, mais pas toujours proprement.

Pourquoi éviter les clones multiples ?

Les clones multiples fonctionnent, oui. Mais ils créent vite de la duplication, de la confusion et des angles morts quand plusieurs tâches avancent en parallèle. Je l’ai vu chez un client avec trois agents IA lancés sur trois sujets différents. Au début, ça semblait simple. Un dossier par tâche. Puis personne ne savait vraiment quel clone avait le dernier commit, quelle branche avait été poussée, et quel changement était encore juste local.

Avec plusieurs clones du même projet, vous copiez le dépôt plusieurs fois sur disque. Chaque clone a son propre dossier .git, son propre état local, ses propres branches récupérées, ses propres références. Ça veut dire que l’historique Git n’est pas partagé immédiatement entre les espaces de travail. Si je commit dans un clone, l’autre ne le voit pas tant que je n’ai pas poussé, récupéré, ou synchronisé correctement.

Les git worktrees, eux, partagent le même dépôt .git, le même historique et les mêmes objets Git. Un objet Git, c’est simplement la donnée interne que Git stocke pour représenter un commit, un fichier, un arbre de fichiers. Avec les worktrees, le coût en plus vient surtout des fichiers checkoutés dans chaque dossier, pas d’une copie complète du dépôt.

Ce point devient important avec le développement assisté par IA. Quand plusieurs agents travaillent sur plusieurs branches, je veux de l’isolation pour éviter qu’ils se marchent dessus. Mais je ne veux pas perdre la coordination Git. Les worktrees donnent exactement ça. Chaque agent a son dossier propre, sa branche propre, tout en restant connecté au même dépôt local.

Usage	Clones multiples	Git worktrees
Espace disque	Copie complète du dépôt à chaque fois, avec son propre .git.	Partage du dépôt Git, seuls les fichiers de travail sont dupliqués.
Visibilité de l’historique	Commits moins visibles entre clones sans push ou fetch.	Historique partagé localement dans le même dépôt.
Isolation du travail	Isolation forte, mais au prix de la duplication.	Isolation par dossier et par branche, sans copier tout le dépôt.
Coordination Git	Plus de coordination mentale, plus de risques d’oubli.	Coordination plus simple, car tout reste lié au même dépôt.
Usage avec agents IA	Pratique au début, vite brouillon quand les agents se multiplient.	Très adapté pour lancer plusieurs agents sur plusieurs branches propres.

Pour moi, c’est la vraie différence. Les clones multiples donnent une séparation physique. Les worktrees donnent une séparation de travail, sans casser la vision globale du dépôt. Et quand l’IA commence à produire vite, cette vision globale devient non négociable.

Quelles commandes connaître ?

Il suffit de connaître quelques commandes pour utiliser les worktrees sans se prendre la tête. Je m’en sers surtout quand je veux isoler plusieurs sujets en parallèle, par exemple une branche pour moi, une autre pour un agent IA, sans que tout le monde se marche dessus.

Commande	Rôle	Cas d’usage et vigilance
git worktree add <path> -b <branch>	Créer un nouveau dossier de travail sur une nouvelle branche.	Pratique pour lancer une feature proprement. Attention à choisir un nom de branche clair, surtout si une IA va pousser du code dessus.
git worktree add <path> <existing-branch>	Ouvrir une branche existante dans un nouveau dossier.	Utile pour reprendre une branche sans quitter ce que vous êtes en train de faire.
git worktree list	Afficher les worktrees actifs, avec leurs branches et commits.	À lancer souvent. Ça évite d’oublier qu’un dossier est encore lié à une branche.
git worktree lock <path>	Verrouiller un worktree côté Git.	Très utile si un agent IA tourne dessus longtemps. Ça évite que Git nettoie ses métadonnées par erreur.
git worktree unlock <path>	Retirer le verrou.	À faire quand l’agent IA a fini ou quand le worktree redevient temporaire.
git worktree remove <path>	Supprimer proprement un worktree.	Ça supprime le dossier de travail, pas la branche. C’est généralement ce qu’on veut.
git worktree prune	Nettoyer les métadonnées restantes.	À utiliser si vous avez supprimé un dossier à la main. Ça remet Git au propre.

Un exemple concret. Si votre projet s’appelle myapp, vous pouvez créer un worktree à côté du dossier principal comme ça. Remplacez myapp par le nom réel de votre projet.

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

Là, Git crée le dossier ../myapp-feat-auth et crée aussi la branche feat/auth. C’est parfait pour donner cette branche à un assistant IA sans toucher à votre dossier principal.

git worktree add ../myapp-fix-payment fix/payment

Ici, j’ouvre une branche qui existe déjà. Je fais souvent ça quand un client me demande une correction urgente pendant qu’une autre évolution est en cours.

git worktree list
git worktree lock ../myapp-feat-auth
git worktree unlock ../myapp-feat-auth
git worktree remove ../myapp-feat-auth
git worktree prune

Le réflexe simple, c’est ça : je crée, je liste, je verrouille si une IA travaille dessus, puis je supprime proprement quand c’est terminé.

Comment démarrer proprement ?

Je démarre toujours depuis une branche principale propre, sinon je déplace juste le désordre dans plusieurs dossiers. C’est le piège classique avec les worktrees Git : on croit isoler le travail, mais si la base est bancale, l’agent IA va juste hériter d’un contexte flou.

Je commence donc par vérifier que Git supporte bien les worktrees. Il faut une version 2.5 ou supérieure. La commande : git –version. Si vous êtes sur une version récente, aucun souci, c’est généralement déjà bon.

Ensuite, je regarde l’état du dépôt principal avec : git status. Ce réflexe évite pas mal de surprises. Si Git me dit que tout est propre, je peux créer mon worktree. Si je vois des fichiers modifiés, des fichiers non suivis, ou un début de refacto oublié, je m’arrête deux minutes.

Quand le travail en cours n’est pas propre, je fais simple. Soit je crée un commit de checkpoint, soit je stash. Le checkpoint est souvent plus lisible, surtout quand je bosse avec un agent IA ou avec un client qui repasse derrière. Exemple : git add . && git commit -m « checkpoint: work in progress ». Ce n’est pas un commit final, c’est juste un point de sauvegarde propre.

Une fois la base saine, je crée mon premier worktree avec : git worktree add ../myapp-feat-auth -b feat/auth. Le chemin ../myapp-feat-auth veut dire que je crée un dossier voisin du projet principal. Pas un sous-dossier à l’intérieur du repo. C’est important, parce qu’on évite de mélanger les fichiers, les builds, les dépendances et les traces laissées par les outils IA dans le même répertoire.

Mon scénario habituel est assez simple. Je garde le dossier principal sur main. Je lance l’agent IA dans ../myapp-feat-auth pour travailler sur l’authentification. Si un hotfix arrive au milieu, je crée un autre worktree dédié. Le contexte de chaque tâche reste en place, sans switch permanent de branche, sans fichiers qui disparaissent, sans panique inutile.

Étape	Action
Vérifier Git	Contrôler la version avec git –version
Vérifier le status	Regarder l’état du dépôt avec git status
Créer un checkpoint	Sauvegarder le travail en cours si le dépôt n’est pas propre
Ajouter le worktree	Créer un dossier voisin avec git worktree add
Lancer l’agent IA	Travailler dans le bon dossier, pas dans le repo principal

Où est le vrai gain avec l’IA ?

Le vrai gain, c’est de pouvoir paralléliser le travail de plusieurs agents IA sans sacrifier le contrôle Git. C’est ça le sujet. Pas juste “aller plus vite”. Aller plus vite dans un dossier sale, avec trois changements mélangés, ça finit rarement bien.

Un agent IA peut modifier beaucoup de fichiers d’un coup. Il peut toucher le front, le back, les tests, la config, parfois même une migration. Il garde une logique locale dans ce qu’il fait, mais cette logique peut être exploratoire. Il tente une piste, il ajuste, il repart ailleurs. Et parfois, franchement, on ne veut pas garder cette direction.

Avec un seul dossier de travail, ça devient fragile. Vous avez une fonctionnalité en cours, l’agent a modifié quinze fichiers, puis une urgence arrive. Là, on connaît la scène. On stash à l’arrache, on change de branche, on prie pour que les dépendances soient encore cohérentes, et on garde dans la tête un état mental complètement bancal.

Avec les worktrees, chaque expérimentation reste dans son couloir. Un worktree, c’est simplement un deuxième dossier de travail lié au même dépôt Git, mais avec sa propre branche checkoutée. Même historique Git, espaces de travail séparés.

Le scénario hotfix devient beaucoup plus propre. Un agent IA bosse sur une fonctionnalité dans un dossier. Une urgence prod tombe. Je crée un autre worktree sur une branche hotfix, je corrige, je teste, je commit. Je n’ai pas besoin d’interrompre l’agent, ni de cacher ses changements, ni de mélanger deux contextes qui n’ont rien à voir.

Chez certains clients, j’ai vu un truc assez net. Le vrai problème n’est pas toujours que l’IA code mal. C’est qu’elle accélère aussi le chaos quand l’environnement de travail n’est pas cadré. Les worktrees posent une limite simple. Chaque agent, chaque sujet, chaque branche a son espace.

Il faut rester lucide quand même. Les worktrees ne remplacent pas les revues de code. Ils ne remplacent pas les tests, les commits propres, les branches bien nommées ou une vraie discipline d’intégration. Ils rendent juste l’organisation plus robuste quand plusieurs tâches avancent en parallèle.

Si vous utilisez un seul agent IA ponctuellement, c’est confortable. Si vous commencez à faire travailler plusieurs agents, ou plusieurs features en même temps, ça devient presque indispensable.

Et si votre prochain agent IA avait son propre espace ?

Les git worktrees ne sont pas une nouveauté exotique, mais ils deviennent vraiment utiles avec le développement assisté par IA. Je peux garder une branche principale propre, isoler une feature, lancer un hotfix, tester une idée avec un agent, puis supprimer le dossier sans perdre la branche. C’est plus léger que plusieurs clones et beaucoup plus clair qu’un seul répertoire où tout se mélange. Le point important, c’est la discipline : un worktree par tâche, un état Git propre, des commandes simples. Vous gagnez surtout en calme, en contrôle et en vitesse quand l’IA commence à travailler avec vous.

FAQ

• Qu’est-ce qu’un git worktree ?
  Un git worktree est un dossier de travail séparé qui reste rattaché au même dépôt Git. Il permet d’avoir plusieurs branches ouvertes en même temps, chacune avec son propre état de fichiers, sans créer plusieurs clones complets du projet.
• Pourquoi les git worktrees sont utiles avec l’IA ?
  Ils isolent le travail de chaque agent IA. Un agent peut modifier une branche dans son dossier, pendant qu’un autre dossier reste disponible pour un hotfix ou une autre feature. Ça évite de casser le contexte, de stasher trop vite ou de mélanger des changements sans rapport.
• Les worktrees remplacent-ils les branches Git ?
  Non. Les worktrees utilisent les branches Git. La différence, c’est qu’ils permettent de travailler sur plusieurs branches en parallèle, dans plusieurs dossiers, au lieu de changer de branche dans un seul répertoire.
• Quelle version de Git faut-il pour utiliser les worktrees ?
  Il faut Git 2.5 ou une version plus récente. Je vérifie simplement avec la commande git –version avant de mettre ça en place sur un poste ou dans un environnement de développement.
• Supprimer un worktree supprime-t-il la branche ?
  Non, la commande git worktree remove <path> supprime le dossier de travail, mais la branche reste disponible. C’est justement pratique pour nettoyer l’espace local sans perdre l’historique de ce qui a été fait.

 

 

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 usages data et IA sans empiler des outils dans tous les sens. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos workflows IA, vos automatisations ou vos environnements data, contactez-moi.