DonnIA
Toutes les ressources
GuideBonnes pratiques12 min

Travailler en parallèle avec les worktrees

Donner à chaque session son propre répertoire de travail, avec git worktree et le drapeau --worktree de Claude Code.


Deux sessions Claude Code dans le même dossier, c'est deux agents qui écrivent dans les mêmes fichiers sans se voir. L'une refactorise, l'autre corrige un bug, et tu passes la soirée à démêler un diff que personne n'a écrit intentionnellement.

La solution n'est pas de tout faire en série. C'est de donner à chaque session son propre répertoire de travail. Un worktree git est exactement ça : un dossier séparé, avec ses fichiers et sa branche, qui partage l'historique et le dépôt distant de ton dépôt principal.

Deux chemins existent : git worktree à la main, et le drapeau --worktree de Claude Code qui fait le travail pour toi. Les deux se mélangent bien.

La syntaxe git, vérifiée

git worktree add [-b <nouvelle-branche>] <chemin> [<commit-ish>]
git worktree list
git worktree remove [-f] <worktree>
git worktree lock / unlock / move / prune / repair

Deux usages qui couvrent presque tout :

git worktree add ../projet-feature-a -b feature-a

crée le dossier ../projet-feature-a sur une nouvelle branche feature-a.

git worktree add ../projet-bugfix fix-issue-456

crée un worktree sur une branche qui existe déjà.

L'ordre des arguments piège tout le monde

C'est git worktree add <chemin> -b <branche>, pas l'inverse : le chemin est l'argument positionnel, la branche est une option. Git accepte les deux ordres puisque -b est une option nommée, mais si tu écris deux chemins, le second sera interprété comme un point de départ, pas comme une destination.

Avant de commencer

  • Un dépôt git avec des tâches vraiment indépendantes
  • Claude Code installé
  • De quoi faire tourner deux installations de dépendances en parallèle

1Laisser Claude Code créer le worktree

Le plus simple : passer --worktree (ou -w) avec un nom.

claude --worktree feature-auth

Par défaut, le worktree est créé sous .claude/worktrees/<nom>/ à la racine du dépôt, sur une nouvelle branche nommée worktree-<nom>. Relance la même commande avec un autre nom dans un second terminal pour ouvrir une deuxième session isolée. Sans nom, Claude Code en génère un du genre bright-running-fox.

Ajoute le dossier à ton .gitignore pour que les worktrees n'apparaissent pas comme fichiers non suivis dans ton dépôt principal :

.claude/worktrees/

Un point à connaître : les lancements interactifs demandent la confiance de l'espace de travail. Si tu n'as jamais lancé claude dans ce dossier, --worktree sort en erreur en te demandant de le faire une fois.

2Préparer l'environnement du worktree

Un worktree est une copie fraîche : node_modules, .venv et .env n'y sont pas. Les dépendances, tu les installes (ou tu demandes à Claude de le faire).

Pour les fichiers ignorés par git, il y a un mécanisme dédié : un fichier .worktreeinclude à la racine du projet, en syntaxe .gitignore.

.env
.env.local
config/secrets.json

Seuls les fichiers qui correspondent à un motif et sont ignorés par git sont copiés, donc les fichiers suivis ne sont jamais dupliqués. Ça s'applique à tous les worktrees créés par Claude Code avec git.

3Choisir la branche de départ

Par défaut, un nouveau worktree part de la branche par défaut du dépôt distant, généralement main. C'est le bon choix pour une tâche neuve, et le mauvais quand tu veux travailler sur ce que tu as en cours.

Dans tes réglages :

{
  "worktree": {
    "baseRef": "head"
  }
}

"fresh" (le défaut) part de la branche par défaut distante, "head" de ton HEAD local, donc avec tes commits non poussés. Le réglage n'accepte pas un nom de branche : pour partir d'une branche précise, crée le worktree avec git directement.

Pour partir d'une pull request, --worktree accepte son numéro préfixé de #, ou une URL GitHub complète. Pense à protéger le # de ton shell :

claude --worktree "#1234"

4Isoler aussi les sous-agents

Un sous-agent peut tourner dans son propre worktree. Pour le rendre permanent, ajoute isolation: worktree au frontmatter, dans .claude/agents/ :

---
name: refactorer
description: Applique des refactors mecaniques sur de nombreux fichiers
isolation: worktree
---

Applique le refactor demande sur tous les fichiers concernes, puis lance les
tests et rapporte les resultats.

Le worktree temporaire est supprimé automatiquement si le sous-agent ne produit aucun changement. S'il en produit, il reste sur le disque jusqu'à ce qu'un balayage périodique puisse le retirer sans perdre de travail.

5Nettoyer

À la sortie d'une session interactive, Claude Code vérifie si le worktree contient du travail : fichiers modifiés ou non suivis, nouveaux commits.

  • Worktree propre, session sans nom : supprimé automatiquement, branche comprise.
  • Worktree propre, session nommée : on te demande d'abord.
  • Worktree avec du travail dedans : on te demande de garder ou de supprimer. Supprimer efface le dossier, la branche, et tout ce qu'ils contiennent.

Les lancements non interactifs avec -p n'ont pas d'invite de sortie, donc personne ne nettoie derrière eux :

git worktree remove .claude/worktrees/feature-auth

Ajoute --force si le worktree a des modifications non commitées ou des fichiers non suivis.

Ce qui est partagé, ce qui ne l'est pas

ÉlémentPartagé avec le dépôt principal
Le répertoire .gitOui, donc git commit fonctionne depuis un worktree
Les plugins installés en portée projetOui, pas besoin de réinstaller par worktree
Les approbations de permissionsOui, elles sont écrites dans le .claude/settings.local.json du dépôt principal
Les fichiers de travail et la brancheNon, c'est tout l'intérêt
Les dépendances installéesNon, chaque worktree a les siennes

Les garde-fous

Tant qu'une session est isolée dans un worktree, Claude Code bloque les appels d'outils qui atteindraient le dépôt principal : les écritures de fichiers vers un chemin du dépôt principal, les commandes dont le répertoire de travail y résout, et les commandes qui redirigent git vers lui (git -C, --git-dir, GIT_DIR, GIT_WORK_TREE, ou un cd avant la commande). Ces contrôles couvrent aussi tous les sous-agents lancés depuis la session isolée.

Le nombre de sessions n'est pas gratuit

Chaque session parallèle est une fenêtre de contexte à part, donc une consommation à part. Deux ou trois worktrees actifs sont gérables et rentables. Au-delà, c'est toi le goulot d'étranglement : tu ne peux pas relire six diffs en même temps, et un diff non relu ne vaut pas mieux qu'un diff non écrit.

La règle de découpage

Un worktree par tâche indépendante, jamais par tâche « qu'on pourrait faire en même temps ». Le test : si les deux tâches touchent les mêmes fichiers, le parallélisme ne t'économise rien, il déplace juste le conflit du moment de l'écriture au moment du merge. Et un conflit de merge sur du code que tu n'as pas écrit toi-même coûte bien plus cher qu'une demi-heure d'attente.

Tu as d’autres ressources comme ça ?

Ce que tu viens de lire est entièrement gratuit. Une nouvelle ressource part chaque semaine dans la newsletter : guides, modèles à copier et liens triés, sans compte à créer.

Cette page est en accès libre, n’hésite pas à la partager.