Comment utiliser Git worktrees avec l’IA ?

Git worktrees permet de travailler sur plusieurs branches du même dépôt sans casser le contexte d’un agent IA, ni jongler avec stash et checkout. C’est simple, natif dans Git, et franchement plus propre que multiplier les clones dès qu’on veut paralléliser le dev.

Pourquoi Git worktrees change le dev avec IA ?

Git worktrees change le développement avec IA parce qu’il donne à chaque tâche, humain ou agent, son propre espace de travail sans dupliquer tout le dépôt. Et dès qu’on commence à faire coder un agent IA pour de vrai, pas juste sur une démo, ça devient vite évident.

Imaginez un cas simple. Vous lancez un agent IA sur une branche feature. Il analyse le code, modifie plusieurs fichiers, lance des tests, garde un contexte mental sur ce qu’il est en train de faire. Pendant ce temps, un incident production tombe. Il faut corriger vite, sur main, avec un hotfix propre.

Avec le workflow Git classique, ça devient fragile. Vous êtes dans le même dossier. Vous avez des fichiers modifiés. Vous devez peut-être faire un stash, changer de branche, espérer que rien ne casse, corriger, revenir, réappliquer le stash. Et l’agent dans tout ça ? Il bossait dans ce dossier. Vous venez de lui changer le sol sous les pieds.

Le vrai problème, ce n’est pas juste Git. C’est toute l’infrastructure autour des agents IA. Un agent qui code a besoin de trois choses très simples :

• Un dossier stable, parce qu’il lit et écrit des fichiers en continu.
• Un état cohérent, parce qu’un fichier à moitié modifié ou déplacé peut casser son raisonnement.
• Une branche qui ne bouge pas, parce qu’il construit son plan sur l’état courant du code.

Git worktrees répond exactement à ça. Ce n’est pas une astuce gadget pour développeur qui aime les commandes Git obscures. C’est une manière propre d’isoler les contextes de travail. Une branche feature peut vivre dans un dossier. Le hotfix sur main dans un autre. L’agent continue sa tâche, vous corrigez la prod à côté, et personne ne marche sur les fichiers de l’autre.

J’ai vu ce problème chez des équipes qui testent plusieurs agents, ou juste plusieurs tâches en parallèle avec Cursor, Claude Code, Copilot Workspace ou des scripts maison. Le premier vrai gain, ce n’est même pas la vitesse. C’est la baisse du chaos. Moins de stash oubliés, moins de branches sales, moins de “attends je finis ça avant de toucher à la prod”.

Pour comprendre pourquoi ça marche aussi bien, il faut regarder ce qu’est vraiment un worktree côté Git.

C’est quoi un worktree Git ?

Un worktree Git est un répertoire de travail séparé, connecté au même dépôt Git, avec son propre état de fichiers et son propre index, tout en partageant l’historique et les objets Git.

Dit simplement, c’est comme avoir plusieurs copies de votre projet ouvertes en parallèle, mais sans refaire plusieurs clones complets. Je garde le même dépôt Git derrière, le même historique, les mêmes commits, les mêmes objets internes, mais chaque dossier de travail vit sa vie.

Dans un dépôt Git classique, vous avez un répertoire principal, par exemple mon-projet. C’est là où vous modifiez vos fichiers. À l’intérieur, Git stocke ses données dans .git, avec l’historique, les branches, les références, les objets, bref tout ce qui permet à Git de savoir où il en est.

Avec git worktree, Git permet officiellement d’avoir plusieurs arbres de travail attachés au même dépôt. Un arbre de travail, c’est juste le dossier où vos fichiers sont visibles et modifiables. Chaque worktree a son propre état local, son propre index, donc sa propre zone de préparation avant commit, mais il reste relié au dépôt Git commun.

En pratique, ça peut donner une structure comme ça :

• mon-projet pour main
• mon-projet-feature-ia pour une branche feature
• mon-projet-hotfix pour un correctif production

Chaque dossier ressemble à un projet normal quand vous l’ouvrez dans votre IDE. Votre éditeur voit des fichiers, un Git actif, une branche courante. Un agent IA aussi. C’est ça qui est intéressant. Vous pouvez demander à un agent de travailler sur mon-projet-feature-ia, garder mon-projet propre sur main, et ouvrir mon-projet-hotfix si la prod brûle un peu.

Les fichiers ne se marchent pas dessus parce que chaque worktree a son propre état local. Vous pouvez avoir un fichier modifié dans la branche feature, un autre état dans le hotfix, et rien qui pollue main. Les commits, eux, restent disponibles dans le même dépôt Git. Si vous commitez dans un worktree, le dépôt connaît ce commit.

C’est souvent là que les équipes me disent : “Ok, mais pourquoi ne pas faire plusieurs clones ?”. C’est une vraie question, et c’est justement la comparaison à faire pour voir où les worktrees deviennent beaucoup plus pratiques.

Pourquoi éviter plusieurs clones ?

Plusieurs clones fonctionnent, mais Git worktrees fait le même travail avec moins de duplication, plus de cohérence et une meilleure coordination native dans Git. C’est la réponse courte. Si vous lancez plusieurs agents IA sur le même projet, ou si vous testez trois pistes en parallèle, cloner le dépôt trois fois paraît simple. Ça marche. Mais ça devient vite lourd.

Avec plusieurs clones, chaque copie embarque son propre historique Git, ses objets, ses références, et parfois tout l’environnement autour. Sur un petit dépôt, on s’en fiche un peu. Sur un monorepo, ou un projet avec beaucoup de dépendances, de fichiers générés, de caches ou de dossiers temporaires, ça peut exploser. J’ai déjà vu des équipes perdre un temps bête juste parce que chaque agent IA travaillait dans son clone, avec son propre état, ses propres installations, ses propres écarts.

Avec Git worktrees, les répertoires de travail sont séparés, mais l’historique et les objets Git sont partagés. Un objet Git, pour faire simple, c’est ce que Git stocke en interne pour représenter les commits, les fichiers et les arbres du projet. Donc vous pouvez avoir un dossier pour une branche de test, un autre pour un hotfix, un autre pour une expérimentation IA, sans recopier tout le dépôt à chaque fois.

Le gain n’est pas seulement l’espace disque. C’est aussi la cohérence. Un commit créé dans un worktree appartient au même dépôt. Vous n’avez pas besoin de vous demander si tel clone a bien récupéré la dernière branche, si tel autre a un remote différent, ou si un agent IA bosse sur une copie silencieusement décalée. Git connaît les worktrees actifs et évite, dans les cas standards, de checkout la même branche dans deux worktrees en même temps. C’est tout bête, mais ça évite des erreurs.

Critère	Plusieurs clones	Git worktrees
Espace disque	Chaque clone duplique l’historique Git et souvent une partie de l’environnement projet.	Les objets Git sont partagés, seuls les fichiers de travail changent selon la branche.
Partage des commits	Les commits existent dans chaque copie, avec besoin de fetch, push ou pull pour synchroniser.	Les commits appartiennent directement au même dépôt local.
Coordination Git	Git ne sait pas vraiment que vos clones sont liés entre eux.	Git garde la liste des worktrees et protège certaines situations risquées.
Lisibilité pour les agents IA	Chaque agent peut se retrouver dans une copie différente, parfois pas à jour.	Chaque agent a son dossier clair, rattaché au même dépôt et à une branche dédiée.
Nettoyage	Il faut supprimer des clones entiers, avec le risque d’oublier des changements locaux.	On retire un worktree proprement, puis Git sait ce qui existe encore.

Le vrai intérêt arrive quand on maîtrise les quelques commandes de base. À partir de là, Git worktrees devient une façon beaucoup plus propre de travailler avec plusieurs branches, plusieurs essais, et plusieurs agents IA en parallèle.

Quelles commandes Git worktrees connaître ?

Les commandes essentielles de Git worktrees tiennent en quelques lignes et suffisent pour construire un workflow propre avec des agents IA. Je les vois comme une petite boîte à outils : créer un espace isolé, vérifier ce qui tourne, protéger un travail en cours, puis nettoyer proprement.

• Pour créer un nouveau dossier de travail sur une nouvelle branche, j’utilise git worktree add <path> -b <branch>. C’est typiquement ce que je fais quand je donne une tâche à un agent IA, par exemple une refonte d’API ou une correction isolée.
• Pour ouvrir une branche existante dans un autre dossier, j’utilise git worktree add <path> <existing-branch>. C’est pratique quand une branche existe déjà, mais que je ne veux pas changer mon dossier principal.
• Pour voir les worktrees actifs, j’utilise git worktree list. Ça évite de perdre le fil, surtout quand plusieurs agents bossent en parallèle sur plusieurs branches.
• Pour protéger un worktree, j’utilise git worktree lock <path>. C’est utile si un agent IA tourne longtemps, ou si le dossier est temporairement déplacé. Git évite alors de le considérer comme nettoyable.
• Pour retirer cette protection, j’utilise git worktree unlock <path>. Je le fais quand le traitement est fini ou quand je reprends la main.
• Pour supprimer proprement un dossier de travail, j’utilise git worktree remove <path>. Ça supprime le dossier, mais pas la branche. C’est plus propre que de faire un rm à la main, parce que Git met aussi à jour ses références internes.
• Pour nettoyer les métadonnées après une suppression manuelle, j’utilise git worktree prune. Ça sert quand quelqu’un a quand même supprimé le dossier directement, ce qui arrive plus souvent qu’on ne veut l’admettre.

Une séquence réaliste ressemble à ça :

git worktree add ../agent-refactor-api -b ia/refactor-api
git worktree list
git worktree lock ../agent-refactor-api

# L’agent IA travaille dans ../agent-refactor-api
# Je relis ensuite les changements, je teste, je commit si c’est bon

git worktree unlock ../agent-refactor-api
git worktree remove ../agent-refactor-api
git worktree prune

La logique est simple : chaque agent a son terrain de jeu, chaque branche reste isolée, et mon dossier principal reste stable. Avant de brancher ça dans un vrai workflow IA, je vérifie juste deux choses : le nommage des branches, et l’endroit où je crée les dossiers. Un mauvais rangement au départ, et ça devient vite pénible à suivre.

Comment démarrer proprement ?

Pour démarrer proprement avec Git worktrees, je pars toujours d’un dépôt principal sain, sans changements non suivis critiques, puis je crée un worktree par tâche.

Git worktree existe depuis Git 2.5, donc ce n’est pas une nouveauté exotique. Mais honnêtement, j’évite les vieilles versions de Git. Une version récente donne moins de comportements bizarres, une meilleure stabilité, et ça compte quand on branche un agent IA dessus pendant deux heures sans le surveiller toutes les cinq minutes.

Avant de créer quoi que ce soit, je vérifie toujours l’état du dépôt principal :

git status

Si j’ai des fichiers modifiés, je les commit ou je les mets de côté avec un stash. Ce n’est pas une règle bureaucratique. C’est juste ce qui évite les surprises quand je lance un agent IA sur une feature, ou quand je dois partir sur un hotfix en urgence pendant qu’un autre travail est en cours.

Pour créer un worktree dédié à une tâche IA, je fais souvent quelque chose comme ça :

git worktree add ../mon-projet-agent -b feature/agent-ia

Ça crée un nouveau dossier à côté du dépôt principal, avec une nouvelle branche. Je peux ouvrir ce dossier dans mon IDE, ou le donner à un agent IA comme environnement isolé. L’agent peut modifier, tester, casser des trucs même, sans polluer mon espace principal.

Pour un hotfix, je peux partir directement de main :

git worktree add ../mon-projet-hotfix main

Ensuite, depuis ce worktree, je peux créer une branche de hotfix si besoin. Par exemple si je veux corriger proprement sans travailler directement sur main.

Les bonnes habitudes sont simples, mais elles changent tout :

• Nommer clairement les dossiers, parce que mon-projet-agent-2-final, ça finit toujours mal.
• Éviter de lancer deux agents IA sur la même branche.
• Supprimer les worktrees terminés.
• Utiliser git worktree list avant de nettoyer.
• Garder le dépôt principal comme point stable, pas comme zone de test permanente.

Situation	Bon réflexe
Feature IA	Créer un worktree avec une branche dédiée.
Hotfix production	Créer un worktree depuis main, puis une branche de correction si besoin.
Revue de branche	Créer un worktree temporaire pour inspecter sans toucher au travail en cours.
Nettoyage	Lancer git worktree list, puis supprimer ce qui est terminé.
Agent long	Lui donner son propre dossier et sa propre branche.

Et si votre prochain agent IA avait enfin son propre espace ?

Git worktrees règle un problème très concret : travailler en parallèle sans casser le contexte. Pour un développeur, c’est déjà confortable. Pour un agent IA, c’est presque indispensable. Chaque tâche garde son dossier, sa branche, son état de fichiers. Le dépôt reste cohérent, les commits sont partagés, et on évite la duplication inutile des clones multiples.

Je ne vois pas ça comme une commande Git de plus à apprendre. Je le vois comme une petite couche d’infrastructure pour coder plus proprement avec l’IA. Le bénéfice pour vous est simple : moins d’interruptions, moins de conflits, et un workflow beaucoup plus fiable.

FAQ

• À quoi sert Git worktrees concrètement ?
  Git worktrees sert à ouvrir plusieurs répertoires de travail pour un même dépôt Git. Chaque répertoire peut être sur une branche différente, avec ses propres fichiers et son propre index. C’est pratique pour gérer une feature, un hotfix et une expérimentation IA sans changer de branche en permanence.
• Git worktrees remplace-t-il les branches Git ?
  Non, Git worktrees ne remplace pas les branches. Il permet plutôt de travailler sur plusieurs branches en même temps, dans plusieurs dossiers séparés. Les branches restent le mécanisme Git principal, le worktree ajoute juste une isolation physique du répertoire de travail.
• Pourquoi Git worktrees est utile avec les agents IA ?
  Un agent IA a besoin d’un environnement stable pour lire, modifier et tester le code. Si vous changez de branche pendant qu’il travaille, vous pouvez casser son contexte. Avec un worktree dédié, l’agent garde son dossier et sa branche, pendant que vous pouvez traiter autre chose ailleurs.
• Quelle différence entre Git worktrees et plusieurs clones ?
  Plusieurs clones créent plusieurs copies complètes du dépôt. Git worktrees partage l’historique et les objets Git avec le dépôt principal, ce qui évite une partie de la duplication et garde une meilleure cohérence. C’est plus propre quand on multiplie les tâches ou les agents.
• Faut-il nettoyer les worktrees après usage ?
  Oui, c’est une bonne habitude. Quand une tâche est terminée, utilisez git worktree remove <path> pour supprimer proprement le worktree. Si un dossier a été supprimé à la main, git worktree prune permet de nettoyer les métadonnées restantes.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et les sujets SEO/GEO. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos workflows IA, data ou automatisation sans bricolage, contactez-moi, je peux vous aider.