Comment utiliser Git worktrees pour coder avec l’IA ?

J’utilise Git worktrees pour donner à chaque agent IA son propre espace de travail, sans casser ma branche en cours. C’est simple, propre, et franchement ça évite les gros moments de solitude quand un hotfix production arrive au milieu d’une feature.

C’est quoi Git worktrees ?

Git worktrees permet d’avoir plusieurs répertoires de travail reliés au même dépôt Git, chacun avec sa branche, son index et ses fichiers.

Dit simplement, vous gardez un seul dépôt Git “réel”, avec le même historique, les mêmes commits, les mêmes objets Git. Mais vous avez plusieurs dossiers de travail séparés. Chaque dossier peut être sur une branche différente, avec ses propres fichiers modifiés, sans marcher sur les pieds des autres.

C’est très pratique dès qu’on code avec l’IA. Je peux laisser un agent IA bosser sur une feature dans un dossier, pendant que je garde un autre dossier propre sur main pour vérifier un bug, relire du code, ou faire un hotfix urgent. Et ça, dans la vraie vie, c’est souvent là qu’on gagne du temps. Pas forcément dans une grosse refonte d’outillage.

Un exemple concret ressemble à ça :

projects/
  myapp/                  # Branche main
  myapp-feat-auth/         # Branche feat/auth, utilisée par un agent IA
  myapp-hotfix-payment/    # Branche hotfix/payment, prête pour une correction rapide

Ce n’est pas juste “un clone en plus”. Avec plusieurs clones, Git recopie beaucoup de choses, et chaque dossier vit un peu sa vie. Avec worktrees, Git sait que tout appartient au même dépôt. Il partage l’historique immédiatement, coordonne les branches proprement, et évite de dupliquer inutilement les objets Git.

Les bénéfices sont assez simples :

• Moins d’espace disque. Vous ne recopiez pas tout le dépôt à chaque fois.
• Historique partagé immédiatement. Les commits et branches restent reliés au même dépôt Git.
• Coordination native par Git. Git sait quelle branche est utilisée dans quel dossier, ce qui évite pas mal d’erreurs bêtes.

Quand un agent IA modifie beaucoup de fichiers, j’aime bien l’isoler dans son propre worktree. Comme ça, je peux comparer, tester, jeter ou garder sans polluer mon espace principal.

Critère	Clone multiple	Git worktrees
Espace disque	Plus lourd, car chaque clone recopie le dépôt.	Plus léger, car les objets Git sont partagés.
Partage de l’historique	Chaque clone doit être synchronisé.	L’historique est commun immédiatement.
Isolation du travail	Oui, mais avec plus de duplication.	Oui, avec une isolation propre par dossier.
Usage avec agents IA	Possible, mais vite désordonné.	Très adapté pour lancer plusieurs tâches en parallèle.

Pourquoi l’IA casse le flux Git ?

L’IA casse le flux Git quand elle perd le contexte après un changement de branche, ou quand elle continue à modifier un espace de travail qui n’est plus celui attendu.

Le scénario classique, je le vois souvent. Un agent IA travaille sur feat/auth. Il a compris les fichiers, il a commencé à modifier le login, les tests, peut-être un middleware. Puis une urgence production arrive. Il faut repasser sur main, créer un hotfix, corriger vite, livrer proprement.

Dans un workflow Git classique, on fait ce qu’on a toujours fait. Un stash pour mettre de côté les changements, un switch vers main, parfois un commit de checkpoint un peu sale parce qu’on veut juste sauver l’état courant. Ça marche, mais avec l’IA ça devient plus fragile. L’agent ne “voit” pas toujours votre intention. Il voit surtout un dossier local qui change sous ses pieds.

Et là les problèmes commencent.

• Le travail en cours peut être abîmé parce qu’un fichier attendu n’est plus dans le même état.
• Des fichiers peuvent être modifiés dans la mauvaise branche, juste parce que l’agent continue là où il pense être.
• Un hotfix peut se retrouver mélangé avec une feature pas prête.
• Vous perdez du temps à reconstruire le contexte, à relire les diffs, à comprendre pourquoi tel fichier a bougé.

Ce n’est pas dramatique, mais c’est pénible. Et surtout, c’est évitable. Chez un client, on avait plusieurs tâches IA qui tournaient en parallèle sur le même repo. Une pour corriger des tests, une pour préparer une migration, une pour bosser sur une nouvelle API. Le souci n’était pas seulement Git. Le vrai souci, c’était l’organisation physique des espaces de travail. Tout le monde, humains comme agents, se marchait dessus dans le même dossier.

C’est exactement là que Git worktrees devient logique. Un worktree, c’est simplement un deuxième répertoire lié au même dépôt Git, mais positionné sur une autre branche. Donc au lieu de tout faire dans un seul dossier, vous avez un répertoire par tâche, un agent par répertoire, une branche claire par objectif.

Votre hotfix vit dans son dossier. Votre feature auth reste dans le sien. L’IA garde son contexte local, les fichiers ne changent pas brutalement, et vous réduisez fortement les mélanges bêtes. La suite, c’est de voir les quelques commandes à connaître pour créer, lister et supprimer ces worktrees sans se compliquer la vie.

Quelles commandes connaître ?

Les commandes essentielles sont git worktree add, git worktree list, git worktree lock, git worktree unlock, git worktree remove et git worktree prune. Avec ça, je couvre 95% de mes usages quand je code avec un agent IA.

La commande que j’utilise le plus, c’est git worktree add. Elle crée un autre dossier de travail, branché sur le même dépôt Git, mais avec sa propre branche. Pratique quand je veux laisser une IA modifier du code sans toucher à mon espace principal.

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

Ici, je crée un worktree dans le dossier ../myapp-feat-auth et je crée en même temps la branche feat/auth. C’est typiquement ce que je fais quand je demande à un agent IA de développer une fonctionnalité d’authentification.

Je peux aussi créer un espace de travail depuis une branche existante, par exemple pour corriger vite un bug depuis main.

git worktree add ../myapp-hotfix main

Pour voir ce qui existe déjà, j’utilise git worktree list. Ça me donne la liste des worktrees actifs, leur chemin, leur branche et le commit associé.

git worktree list

Avec les agents IA, je verrouille souvent un worktree pendant qu’un agent travaille dessus. Ça évite de le supprimer par erreur, surtout quand plusieurs tests tournent en parallèle. J’ai déjà vu un client nettoyer un dossier “temporaire” alors que Cursor était encore en train de modifier des fichiers dedans. Pas dramatique, mais pénible.

git worktree lock ../myapp-feat-auth
git worktree unlock ../myapp-feat-auth

Quand le travail est terminé, je supprime proprement le worktree avec git worktree remove. Puis j’utilise git worktree prune pour nettoyer les références obsolètes, par exemple si un dossier a été supprimé à la main.

git worktree remove ../myapp-feat-auth
git worktree prune

Commande	Usage	Moment où je l’utilise avec l’IA
git worktree add	Créer un nouvel espace de travail	Quand je lance un agent sur une feature ou un hotfix isolé
git worktree list	Voir les worktrees actifs	Quand je veux vérifier où travaillent mes agents
git worktree lock	Protéger un worktree	Quand un agent IA est en train de modifier du code
git worktree unlock	Déverrouiller un worktree	Quand l’agent a terminé et que je veux nettoyer
git worktree remove	Supprimer proprement un worktree	Quand la branche a été mergée ou abandonnée
git worktree prune	Nettoyer les références mortes	Quand j’ai supprimé des dossiers ou fait du ménage

Comment le mettre en place ?

Je mets Git worktrees en place en partant d’un dépôt propre, puis je crée un dossier dédié par tâche ou par agent IA. C’est vraiment l’idée centrale. Un agent, un espace de travail, une branche claire. Ça évite que l’IA modifie votre feature pendant que vous êtes en train de corriger un bug ailleurs.

Le prérequis est simple : Git worktree existe depuis Git 2.5. Je vérifie toujours la version avant de commencer.

git --version

Avant de créer quoi que ce soit, je regarde l’état du dépôt. Je veux savoir si j’ai des fichiers modifiés, non suivis, ou un début de travail qui traîne.

git status

Si je veux garder le travail en cours, je fais un commit de checkpoint. Ce n’est pas un commit parfait, c’est juste un point de sauvegarde propre.

git add .
git commit -m 'checkpoint: work in progress'

Si c’est vraiment temporaire, je stash. Le stash, c’est une mise de côté locale des changements, sans créer de commit.

git stash push -m "temp: before worktree"

Ensuite je crée mon premier worktree. Là, je prépare une feature d’authentification dans un dossier séparé.

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

Le dossier ../myapp-feat-auth devient l’espace de travail de l’agent IA pour cette feature. Je peux ouvrir ce dossier dans mon IDE, lancer Claude Code, Cursor, Windsurf ou autre, et le laisser travailler sans toucher à mon dépôt principal.

Pour un hotfix, je peux aussi partir de main dans un autre dossier.

git worktree add ../myapp-hotfix main
cd ../myapp-hotfix
git switch -c hotfix/login-crash

Si main est déjà utilisé ailleurs, Git peut râler. Dans ce cas, je crée directement une branche depuis main avec la commande adaptée. Le point important reste le même : le hotfix vit dans son propre dossier.

Je garde une convention de nommage très bête : nom du projet plus nom court de la tâche. Par exemple myapp-feat-auth, myapp-hotfix-login, myapp-refactor-billing. Ça paraît bête, mais quand trois agents tournent, c’est exactement ce qui évite les erreurs. J’ai déjà vu un client perdre une heure juste parce que deux fenêtres VS Code avaient presque le même nom.

• Dépôt propre avant de créer un worktree.
• Un agent IA par worktree, pas deux agents dans le même dossier.
• Nom de dossier explicite, avec projet et tâche.
• Lock pendant les runs longs avec git worktree lock si besoin.
• Prune régulier avec git worktree prune pour nettoyer les références mortes.

Quelles bonnes pratiques garder ?

Les bonnes pratiques sont simples : garder des worktrees courts, lisibles, verrouillés quand nécessaire, et supprimés dès qu’ils ne servent plus. Je les vois comme des établis temporaires. Propres, utiles, mais pas faits pour rester au milieu du garage pendant trois mois.

Un worktree n’est pas un deuxième dépôt qu’on oublie dans un coin. Je l’utilise comme un espace de travail temporaire, mais propre. Une feature est mergée ? Je supprime le worktree. Une idée est abandonnée ? Pareil. Je préfère fermer vite plutôt que laisser traîner des dossiers qui vont finir par me faire douter de l’état réel du projet.

git worktree remove ../mon-projet-feature-ia
git worktree prune

La commande git worktree remove supprime proprement le dossier lié au dépôt. La commande git worktree prune nettoie les références mortes si Git garde encore des traces d’anciens worktrees. C’est le petit coup de balai qui évite les surprises.

Avec des agents IA en parallèle, le bon usage est assez naturel. Un agent travaille sur une feature. Un autre corrige un bug. Un troisième explore une piste un peu risquée. Chacun dans son dossier, chacun sur sa branche, chacun avec son contexte. J’ai vu ça très bien marcher chez un client qui testait deux approches de refonte API en même temps. Sans worktrees, c’était vite le bazar. Avec, on savait exactement qui faisait quoi.

• Un agent IA doit recevoir le bon chemin de travail, pas juste “le repo”.
• Un développeur doit garder la main sur les commits.
• Une review humaine reste obligatoire, surtout si l’IA touche à du métier ou à de la sécurité.
• Les merges doivent rester volontaires, pas automatiques parce qu’un agent “a fini”.

Les erreurs classiques, je les ai presque toutes vues. Lancer deux agents dans le même worktree, c’est demander des conflits bêtes. Changer de branche pendant qu’un agent écrit du code, c’est encore pire. Oublier un git status avant de reprendre la main, ça finit souvent en “attends, il vient d’où ce fichier ?”. Supprimer le dossier à la main sans nettoyer Git laisse aussi des références inutiles. Et laisser trop de worktrees vivre trop longtemps recrée exactement le problème qu’on voulait éviter.

Git worktrees ne remplace pas une discipline Git. Ça la rend juste plus simple à tenir quand l’IA accélère le rythme.

On garde quoi comme méthode maintenant ?

Je garderais une règle simple : dès qu’un agent IA travaille sur une tâche qui peut durer, je lui donne son propre worktree. Ça évite de stasher dans l’urgence, de changer de branche sous ses pieds, ou de mélanger une feature avec un hotfix production. Git worktrees apporte juste ce qu’il faut d’isolation, sans multiplier les clones ni perdre le partage de l’historique Git. Les commandes sont peu nombreuses, donc l’habitude vient vite. Le vrai bénéfice pour vous, c’est un workflow IA plus stable, plus lisible, et moins risqué quand plusieurs sujets avancent en même temps.

FAQ

• À quoi sert Git worktrees avec un agent IA ?
  Git worktrees sert à donner à chaque agent IA un répertoire de travail isolé, relié au même dépôt Git. L’agent peut continuer sa tâche sur sa branche sans être perturbé par un changement de contexte, un hotfix ou une autre expérimentation.
• Git worktrees remplace un clone Git classique ?
  Pas exactement. Un clone crée une copie complète du dépôt. Un worktree partage le même dépôt Git, le même historique et les mêmes objets, tout en offrant un espace de travail séparé. Pour gérer plusieurs branches en parallèle, c’est souvent plus léger et plus propre.
• Quelle version de Git faut-il pour utiliser worktrees ?
  Git worktree est disponible depuis Git 2.5. Je vérifie toujours avec git –version avant de standardiser ce workflow dans une équipe, surtout sur des machines anciennes ou des environnements d’intégration un peu figés.
• Peut-on lancer plusieurs agents IA en parallèle avec Git worktrees ?
  Oui, c’est même l’un des usages les plus intéressants. Je crée un worktree par agent ou par tâche, avec une branche dédiée. Ça limite les collisions de fichiers et ça garde une séparation claire entre feature, hotfix et exploration.
• Quelles erreurs éviter avec Git worktrees ?
  J’évite surtout de lancer deux agents dans le même worktree, de changer de branche pendant qu’un agent travaille, de supprimer un dossier à la main sans passer par git worktree remove, et de laisser traîner des worktrees obsolètes sans git worktree prune.

 

 

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 rendre leurs systèmes data, IA et automatisation plus fiables, pas juste plus à la mode. 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 structurer vos usages IA, data ou automatisation, contactez-moi, je peux vous aider.