On en parle partout des IA, et soyons honnêtes, elle est en train de transformer notre métier. Entre les assistants de code, les générateurs de tests et les agents autonomes qui promettent de coder des features entières, nos dépôts Git risquent de devenir de vrais champs de bataille. Personnellement, j'ai commencé à jouer avec quelques agents qui génèrent des PR, des bouts de code, des refactorings… et très vite, j'ai réalisé un truc : la gestion de ces multiples branches, de ces environnements de travail parallèles, ça devenait un cauchemar. Mes git stash s'accumulaient, mes changements se mélangeaient, et la peur de perdre un truc important me guettait à chaque git checkout.
C'est là que j'ai (re)découvert les Git worktrees. Une fonctionnalité puissante, souvent sous-estimée, mais dont l'interface native est, disons-le, un peu rustique. Et puis, j'ai mis la main sur Worktrunk. Un outil CLI en Rust qui m'a non seulement réconcilié avec les worktrees, mais qui a aussi transformé ma façon de collaborer avec mes nouveaux "collègues" IA...
Git Worktrees : l'allié des développeurs modernes
Pour ceux qui ne connaissent pas, un Git worktree, c'est une copie de votre dépôt Git, mais dans un répertoire séparé, pointant vers une branche différente. L'intérêt ? Vous pouvez travailler sur plusieurs branches en même temps, sans avoir à jongler avec les git checkout qui réécrivent votre répertoire de travail. Imaginez : une branche pour la feature A, une autre pour le bug B, et une troisième pour la revue de code de la PR X. Chaque worktree a son propre état de travail, ses propres fichiers modifiés, sans interférer avec les autres. C'est génial pour le contexte switching rapide.
Le hic ? Les commandes natives git worktree add, git worktree list, git worktree remove… ça fonctionne, mais ce n'est pas hyper ergonomique. Surtout quand vous commencez à avoir une dizaine de worktrees. C'est là que Worktrunk entre en jeu, pour corriger cette expérience utilisateur "peu pratique" et la rendre aussi fluide que la gestion de branches.
Worktrunk : l'orchestrateur de worktrees en Rust
Worktrunk, ou wt pour les intimes, est un CLI écrit en Rust. Son objectif est clair : simplifier la gestion de vos worktrees Git pour optimiser vos workflows de développement. Il est particulièrement pensé pour les scénarios où vous avez besoin de nombreux environnements de travail isolés, ce qui est parfait quand vous travaillez avec des agents IA comme Claude Code ou Gemini CLI qui génèrent du code en parallèle.
Maintenu par Maximilian Roos (max-sixty sur GitHub), Worktrunk est un projet jeune (lancé début 2026, avec une v0.79.0 en septembre 2026), mais déjà très abouti et performant. Il apporte une surcouche d'ergonomie et de fonctionnalités bien pensées par-dessus les commandes Git natives.
Installation rapide et prise en main de Worktrunk
L'installation est un jeu d'enfant. Worktrunk est disponible via les gestionnaires de paquets classiques. La chose la plus importante à retenir : l'étape wt config shell install est cruciale, car elle intègre Worktrunk à votre shell pour qu'il puisse changer de répertoire automatiquement.
Via Cargo (si vous avez Rust) :
cargo install worktrunk && wt config shell install
Sur macOS / Linux (avec Homebrew) :
brew install worktrunk && wt config shell install
Sur Windows (avec Winget) :
Attention, sur Windows, wt est le nom de Windows Terminal. Worktrunk s'installe donc sous l'alias git-wt.
winget install max-sixty.worktrunk && git-wt config shell install
Sur Arch Linux (avec Paru) :
paru worktrunk-bin && wt config shell install
Une fois installé, vous devriez pouvoir commencer à l'utiliser. Les commandes de base sont très intuitives :
wt list: pour voir tous vos worktrees actifs.wt switch <branche>: pour basculer vers un worktree existant ou en créer un.wt remove <branche>: pour supprimer un worktree.wt merge: une commande magique pour fusionner une branche et nettoyer le worktree associé en une seule fois.
Pour créer un nouveau worktree pour une fonctionnalité, par exemple :
wt switch --create feature-auth
Magique ? Non, juste pratique. Plus besoin de se souvenir des chemins d'accès ou des options de git worktree add.
Workflows augmentés par l'IA : un worktree par tâche ou par agent
C'est ici que Worktrunk brille vraiment pour moi. Quand je travaille avec un agent IA, je veux lui donner un environnement propre, isolé, pour qu'il puisse faire ses modifications sans polluer mon travail en cours ou celui d'un autre agent. Worktrunk me permet de faire ça très facilement :
- Un worktree par tâche : J'assigne une tâche spécifique à un worktree. Par exemple,
wt switch --create agent-feature-x. L'agent travaille dans ce répertoire. - Un worktree par agent : Si j'ai plusieurs agents concurrents, chacun peut avoir son worktree. Worktrunk a même des intégrations de plugins pour des agents comme Claude Code, Codex ou Gemini CLI. Par exemple, pour lancer Claude avec une tâche sur un worktree dédié :
wt switch -x claude -c feature-a -- 'Add user authentication'
Cette commande va créer (ou basculer vers) un worktree pour feature-a, puis y lancer l'agent Claude avec la consigne "Add user authentication". L'agent travaille de manière isolée, et je peux facilement revoir ses modifications, les valider, ou le laisser continuer sur une autre tâche sans que mes autres worktrees soient affectés.
Des configurations astucieuses
Worktrunk ne s'arrête pas là. Il supporte des fichiers de configuration :
~/.config/worktrunk/config.tomlpour vos préférences utilisateur (comme le modèle de chemin des worktrees)..config/wt.tomlpour la configuration spécifique au projet (partagée avec l'équipe).
Ces fichiers permettent de définir des "hooks" pour automatiser des actions. Par exemple, installer les dépendances à la création d'un worktree ou lancer les tests avant une fusion :
# .config/wt.toml
[pre-start]
deps = "composer install --no-interaction"
[pre-merge]
tests = "php bin/phpunit"
Dans cet exemple, le hook pre-start installe les dépendances avant de lancer le travail dans le nouvel environnement. Le hook pre-merge exécute les tests avant la fusion : si la commande échoue, l’opération s’arrête. Les commandes sont évidemment à adapter à votre projet. Si vous utilisez npm, remplacez-les par npm ci et npm test. Le principe reste le même : automatiser les étapes répétitives, et mettre quelques garde-fous entre le code produit et la branche principale.
Worktrunk distingue les hooks pre-*, qui sont bloquants, des hooks post-*, exécutés en arrière-plan. Ces derniers peuvent notamment servir à démarrer un serveur de développement. Et puisque la configuration du projet contient des commandes exécutables, Worktrunk demande leur approbation à la première utilisation. Un détail appréciable quand on récupère un dépôt qui ne vient pas de chez soi.
Attention : un worktree n’est pas une machine virtuelle
C’est probablement le point le plus important à comprendre avant de lancer trois agents en parallèle : les worktrees séparent les fichiers de travail, mais ils ne créent pas trois machines indépendantes. Ils partagent le même dépôt Git sous-jacent, notamment les objets, les branches et les références distantes. Et surtout, ils ne séparent pas automatiquement vos services.
Dans un projet PHP avec Docker, par exemple, deux worktrees peuvent très bien tenter de démarrer des conteneurs avec les mêmes noms, d’exposer le même port ou de modifier la même base de données. Résultat : votre code est bien rangé dans des dossiers distincts, mais vos environnements se marchent quand même dessus. Le bazar a simplement changé d’étage.
Pour travailler réellement en parallèle, il faut donc prévoir quelques ajustements :
- Des projets Docker Compose distincts : attribuer un nom de projet différent à chaque environnement, et éviter les noms de conteneurs fixes qui empêchent cette séparation.
- Des ports disponibles : deux serveurs web ne peuvent pas écouter simultanément sur le même port de la même machine.
- Des bases de données séparées : particulièrement si les agents créent des migrations ou exécutent des tests qui modifient les données.
- Une configuration locale adaptée : les fichiers ignorés par Git, comme un
.env.local, ne sont pas automatiquement présents dans un nouveau worktree.
Les hooks prennent alors tout leur intérêt : ils permettent de préparer ces environnements sans refaire les mêmes manipulations à chaque nouvelle tâche. Mais Worktrunk ne peut pas deviner comment votre application doit être isolée. Cette partie reste à organiser dans le projet.
Les agents produisent du code, je garde la revue
Avec cette organisation, mon workflow devient assez simple : une tâche clairement définie, une branche, un worktree, puis une revue du résultat. Je peux laisser un agent avancer sur une fonctionnalité pendant que je vérifie une correction ailleurs, sans interrompre son travail ni transporter mes modifications dans un stash de plus.
En revanche, avoir un environnement séparé ne rend pas le code automatiquement correct. Un agent peut parfaitement produire une mauvaise solution dans un dossier impeccablement organisé. Avant d’intégrer ses changements, je regarde le diff, je vérifie les choix techniques et je lance les contrôles du projet. Les tests automatiques sont utiles, mais ils ne remplacent pas la compréhension de ce qui a été modifié.
La commande wt merge mérite d’ailleurs qu’on s’y attarde avant de l’utiliser machinalement : elle automatise plusieurs étapes d’intégration et de nettoyage. C’est pratique, mais autant consulter son aide et comprendre son comportement avant de lui confier une branche contenant plusieurs jours de travail. Le mot « magique » fait sourire dans un article ; dans un historique Git, je préfère savoir ce qui se passe.
Est-ce que ça vaut le coup sans IA ?
Oui, et c’est même dommage de réduire les worktrees aux agents. Vous développez une fonctionnalité et un bug urgent tombe en production ? Vous pouvez ouvrir un autre environnement sans toucher à votre travail en cours. Une PR à relire ? Même principe : vous récupérez la branche dans son propre dossier, vous lancez l’application et vous testez les changements.
Si vous travaillez toujours sur une seule branche à la fois, Worktrunk ne changera probablement pas votre quotidien. Mais dès que vous alternez entre plusieurs tâches, il enlève une friction bien réelle. Les agents IA rendent simplement ce besoin plus visible : quand plusieurs tâches avancent simultanément, jongler avec un seul répertoire devient vite pénible.
Moins de jonglage, plus de développement
Ce que j’apprécie avec Worktrunk, c’est qu’il ne cherche pas à remplacer Git. Il rend plus accessible une fonctionnalité qui existe déjà et qui répond à un problème concret : travailler sur plusieurs sujets sans devoir ranger tout son bureau à chaque changement de contexte.
Les agents IA accélèrent la production de code. Encore faut-il pouvoir accueillir ce code, le tester et le relire sans transformer son dépôt en vide-grenier. Un worktree par tâche, quelques hooks bien choisis et des environnements correctement séparés : ce n’est pas spectaculaire, mais ça rend le travail beaucoup plus agréable.
Et si ça peut m’éviter de retrouver un stash@{7} nommé « truc temporaire à ne surtout pas perdre », je considère déjà que l’outil a rempli sa mission.
Pour explorer le projet : la documentation officielle de Worktrunk et son dépôt GitHub.