Worktree, ton meilleur ami ?

On est en février 2026. Laisser Claude, Codex, Devstral (et Kimi qui enflamme les réseaux) bosser pendant que tu supervises est devenu un vrai workstyle. Tu as écrit des AGENTS.md, des skills, des CLAUDE.md, tu es très chaud sur toutes les bonnes pratiques que t'as lues sur le net.

Tu maîtrises et ton agent préféré a la main sur le plan que tu as crafté avec amour pendant des heures, il tourne, longtemps. Et maintenant, que faire ? Prendre un café, faire du sport, dormir ? Non, tu as été entraîné pendant 15 ans à bosser comme un idiot pendant 8 heures, pas question de rester les bras croisés dès qu'un agent fait ton boulot d'avant. Tu vas donc multitasker : ouvrir une autre feature, mettre à jour de la doc, revoir un test qui date de trois semaines... mais tu te heurtes à un mur. Ton agent est occupé. Tu ne veux pas le déranger. Tu veux lancer un nouveau truc sans cloner une seconde fois ton repo.

Tu vas utiliser git worktree. C'est ton nouveau meilleur ami.

Pourquoi un worktree ?

Parce que tu veux rester dans le même dépôt, garder les mêmes remotes, et travailler sur une autre branche ou expérimentation pendant qu'un agent continue d'écrire du code sur la branche principale. Créer un worktree, c'est comme ouvrir une nouvelle fenêtre sur ton repo. C'est une copie complète qui pointe vers une autre branche.

Tu fais :

git worktree add ../mon-prochain-truc feature/autre-chose

Tu te retrouves avec un dossier ../mon-prochain-truc, tu y ouvres un nouveau terminal, tu peux commencer du code, des docs, une revue de tests… l'agent continue à tourner là où tu es resté.

Le petit truc surprenant, mais terriblement évident, c'est qu'il faut créer ce répertoire en dehors de l'arbre courant actuellement géré par git. D'où le ../. Ce n'est pas une espèce d'environnement interne ou autre, c'est vraiment une copie ailleurs qu'il faut penser à nettoyer.

Comment je l'utilise

1. Je réserve les worktrees aux tâches courtes (doc, tests, ticket de bug). L'agent est déjà parti sur la branche principale et j'ai pas la largeur d'esprit de lancer plusieurs gros changements en même temps.
2. Je crée un worktree vers une branche dédiée au même niveau que mon repo courant, par exemple <monrepo>-<mabranche>.
3. J'ouvre un autre terminal, je travaille, je commit, je pousse, et je reviens sur la branche principale quand j'ai besoin d'évaluer ou réintégrer ce que l'agent a généré.

Quand j'ai fini, je supprime le worktree :

git worktree remove ../mon-prochain-truc

Le dossier disparaît, mais le travail reste sur la branche associée et ça, c'est royal. Plus qu'à push !

Quelques garde-fous

• Fais attention aux fichiers non suivis : un worktree a ses propres modifications. Comme toujours, commit ou stash avant de supprimer le worktree.
• Tu peux ouvrir plusieurs worktrees, mais garde en tête que chaque branche a son propre HEAD. Ne mélange pas les chemins de build ou les environnements virtuels sans faire attention.
• Si tu utilises un agent pour merger ou rebaser, laisse-le terminer avant de supprimer le worktree.

Dans ce monde où la hustle culture est reine, git worktree te donne les pleins pouvoirs pour la productivité infinie, mais aussi pour une belle explosion de charge mentale. On parlera de cette problématique dans le prochain post. Pense à t'abonner à la newsletter, garde cette astuce près de toi, va à ton rythme et fais attention à ta santé.