Git Worktrees : ce que c’est, comment les utiliser, et pourquoi l’IA change tout
Une commande, un nouveau répertoire, votre travail courant intact. Et si git stash était la mauvaise réponse depuis le début ?
TLDR;
git worktreeexiste depuis 2015 et permet de travailler sur plusieurs branches en parallèle, sans stash ni interruptionChaque worktree est un répertoire distinct lié au même dépôt Git : même historique, même
.git, branches isoléesLes cas d’usage immédiats : hotfix urgent, code review sans friction, comparaison entre deux versions
Avec les agents IA (Claude Code, Cursor...), les worktrees sont devenus indispensables pour faire tourner plusieurs instances sans conflits
Quelques précautions à connaître : pas deux fois la même branche,
npm installà répéter par worktree, etgit worktree prunepour garder tout propre
Que vous soyez junior ou plus avancé, vous utilisez Git tous les jours depuis des mois voire des années et il y a une commande que vous n’avez probablement jamais tapée mais qui refait surface avec la montée en puissance de l’IA. Une commande qui rend le stash dispensable, qui permet de travailler sur 5 branches en même temps sans rien interrompre et qui est en train de devenir le standard pour quiconque travaille avec Claude ou autre.
Il s’agit de git worktree.
Cette commande existe depuis Git 2.5, soit 2015. Si vous ne la connaissez pas encore, ce n’est pas grave, on va l’étudier ensemble et vous allez l’adopter dans les 10 prochaines minutes.
Le problème que vous avez eu 50 fois
On est vendredi (c’est dingue comme on prend souvent ce jour comme référence :D), il est 14h. Vous êtes au milieu d’une feature complexe, à moitié faite avec des fichiers modifiés partout. Un de vos collègues vous envoie ce message :
“Hey, y’a un bug en prod, t’as 5 min ?”
Plusieurs choix s’offrent à vous :
git stashet espérer que vous vous souviendrez du contexte dans 2hCommiter avec un message honteux type “WIP do not review” qui traînera dans l’historique
Ouvrir un clone du projet dans un autre dossier : ce que peu de gens pensent à faire et qui est pourtant la meilleure idée, mais please pas de copier-coller à l’arrache !
C’est exactement ce que font les worktrees, mais de façon propre et intégrée à Git.
Ce que c’est, concrètement
Un worktree, c’est un répertoire de travail supplémentaire lié au même dépôt Git. Pas une copie, pas un clone : le même .git, la même base d’objets, le même historique. Juste un autre dossier dans lequel une autre branche est checkout en parallèle.
Voici la commande de base :
git worktree add ../mon-projet-hotfix hotfix/login-bugElle va créer un dossier mon-projet-hotfix au niveau supérieur de votre projet, avec la branche hotfix/login-bug déjà checkout. Vous pouvez y aller, corriger le bug, faire votre commit, pendant que votre feature en cours reste intacte dans le répertoire original. Aucun stash, aucune interruption.
git worktree list # voir tous vos worktrees actifs
git worktree remove ../mon-projet-hotfix # nettoyer une fois terminé
git worktree prune # supprimer les références orphelinesC’est tout, fin de l’article ! Merci de m’avoir lu !
Blague à part, comme vous pouvez le voir, techniquement, c’est simple. Voyons maintenant quelques cas d’usage que vous rencontrerez tôt ou tard.
Les cas d’usage que vous croiserez vite
La hotfix qui tombe au mauvais moment : on vient d’en parler. C’est le cas numéro un, le plus évident.
La code review sans friction : quelqu’un vous assigne une PR. Plutôt que de stash ce que vous faites et de changer de branche, vous créez un worktree pour la branche à reviewer. Vous lisez le code, vous laissez vos commentaires, vous fermez ce dossier. Votre travail courant n’a jamais bougé.
Le monorepo avec plusieurs apps : si vous avez un frontend et un backend dans le même repo, un worktree par partie peut simplifier les runs parallèles : chaque terminal pointe sur son répertoire, aucune confusion.
La comparaison visuelle entre deux versions : parfois, vous voulez voir comment se comportait l’app il y a trois jours, sans toucher à votre branche actuelle. Un worktree sur un commit précis, un
npm run devsur un autre port, les deux dans le navigateur en même temps.
Pourquoi l’IA a tout changé
Jusqu’ici, les worktrees étaient un outil utile pour les développeurs qui jonglaient avec beaucoup de contextes.
Puis sont arrivés les agents IA : Claude Code, Cursor, Copilot, etc., vous les connaissez. Et là, les worktrees sont devenus le maillon manquant.
Voilà le problème avec les agents IA : ils travaillent sur vos fichiers, ils modifient du code, ils font des commits, ils lancent des commandes. Si vous faites tourner deux agents en même temps sur le même répertoire de travail, c’est le chaos : conflits de fichiers, modifications écrasées, états incohérents.
Les worktrees règlent donc ce problème. Chaque agent a son propre répertoire isolé, sa propre branche, son propre contexte. Ils partagent l’historique Git, mais ne se marchent jamais dessus.
L’équipe de incident.io a publié l’année dernière un retour d’expérience intitulé How we’re shipping faster with Claude Code and Git Worktrees qui donne une idée de l’échelle. En quatre mois, ils sont passés de zéro à 4–5 instances de Claude Code tournant en parallèle. Leur workflow : un script qui crée un worktree, lance l’agent et gère tout le cycle de vie. Un éditeur JavaScript écrit en 10 minutes. Une optimisation d’API qui améliore les performances de 18% pour 8 dollars de crédits Claude. Leur CTO résume comme ça :
“C’est comme avoir une équipe distribuée de développeurs juniors, chacun travaillant sous ma direction.”
Les worktrees ne sont donc pas un gadget isolé, mais un outil bel et bien utilisé par les équipes aujourd’hui.
# Le pattern le plus courant : un worktree par tâche IA
git worktree add ../projet-feature-auth feature/auth-refactor
cd ../projet-feature-auth
claude # ou cursor, ou votre outil préféréL’agent travaille dans son répertoire, vous supervisez et vous mergez ce qui vous convient.
Setup pratique
Quelques ajustements pour que ça devienne fluide au quotidien.
Organisez vos worktrees dans un dossier dédié. Beaucoup de développeurs créent un dossier ../branches/ ou ../worktrees/ au niveau parent du projet. Ça garde tout lisible :
# Au lieu de ../mon-projet-hotfix dans tous les sens
git worktree add ../branches/hotfix-login hotfix/login-bugVous pouvez même créer des alias pour aller plus vite :
# Dans votre .zshrc ou .bashrc
alias gwt="git worktree"
alias gwta="git worktree add"
alias gwtl="git worktree list"
alias gwtrm="git worktree remove"Cependant, attention au coût des dépendances : un worktree partage le code source Git, mais pas vos node_modules. Chaque nouveau worktree sur un projet JavaScript nécessite un npm install. Sur des projets légers, ça représente quelques secondes, mais sur un monorepo avec 2000 dépendances, ça peut prendre plusieurs minutes.
Petit cadeau : pour les workflows avec agents IA, voici un script d’initialisation qui crée le worktree ET installe les dépendances ce qui évite de devoir y penser à chaque fois :
#!/bin/bash
# new-worktree.sh
BRANCH=$1
DIR="../branches/$BRANCH"
git worktree add "$DIR" -b "$BRANCH"
cd "$DIR" && npm install
echo "Worktree prêt dans $DIR"Quelques points d’attention
Une branche ne peut être checkout que dans un seul worktree à la fois. Si vous essayez d’ouvrir la même branche dans deux worktrees, Git refusera avec une erreur.
Et si vous supprimez manuellement un dossier de worktree sans passer par git worktree remove, Git ne le sait pas. git worktree prune nettoie ces références orphelines : c’est une bonne habitude à prendre de temps en temps.
Que faire à partir de maintenant ?
Scott Chacon, co-fondateur de GitHub, a écrit une analyse détaillée des worktrees sur le blog GitButler, intitulée Git Worktrees and GitButler, avec une comparaison entre worktrees et leur approche de “virtual branches”. Ça vaut la lecture si le sujet vous intéresse vraiment et notamment si vous vous demandez pourquoi certains outils comme GitButler (dont on parlait récemment) ont choisi une direction différente.
La documentation officielle Git est aussi complète et directe : git help worktree.
Cette semaine, lorsqu’un collègue vous demandera “t’as 5 min pour ce bug ?”, créez votre premier worktree au lieu de stasher votre travail.
Si cet article vous a été utile, partagez-le à quelqu'un qui ne jure encore que par git stash. Et si vous n'êtes pas encore abonné, rejoignez-nous !
intéressant merci pour le partage 🙏